JVM

JVM结构

1. 简述一下JVM

   • 虚拟机概念：

     • 虚拟机是模拟计算机执行虚拟计算机指令的软件，分为系统虚拟机[Virtual Box、VMware提供操作系统，对物理计算机仿真]和程序虚拟机[JVM执行Java字节码指令]

     • JVM的工作原理是装载二进制字节码，把二进制字节码解释编译为运行平台的机器指令交给底层硬件执行

       • 二进制码只是一个跨平台的通用契约，内部包含的仅仅是一些能被JVM识别的字节码指令、符号表以及其他辅助信息；操作系统只能识别机器指令或者汇编指令；需要将字节码指令翻译成机器指令操作系统才能识别执行

     • 虚拟机是相对于物理机的概念，虚拟机和物理机都有代码执行能力，区别是物理机的执行引擎直接建立在处理器、缓存、指令集和操作系统层面上，虚拟机的执行引擎是由软件自行实现的，虚拟机可以不受物理条件的制约限制指令集与执行引擎的结构体系；物理机的指令集都是和物理硬件深度绑定，比如X86架构和ARM架构的指令集千差万别；虚拟机能在不同硬件平台上执行同一套指令集；但是执行效率相较于物理机略差一些

   • JVM特点：

     • 一次编译，处处运行；自动内存管理；自动垃圾回收机制

     • Java虚拟机是对JVM规范的实现，oracle发布JVM规范，提供HotSpot作为openJDK和oracleJDK的默认虚拟机，不同厂商针对JVM规范有各自的虚拟机实现

     • JVM是一种跨语言平台，JVM的执行基础是字节码文件，JDK7以后JVM通过JSR292规范实现字节码文件可以由任意语言通过编译器编译获得，只要编译后的字节码文件遵循JVM规范就可以被JVM识别、装载和运行；该特点让JVM具备在大型平台上实现多语言混合编程解决特定领域问题的能力

     • 使用基于栈的指令集架构

     • 主流虚拟机都采用解释器和JIT即时编译器混合工作模式

   • JVM的生命周期

     • 启动

       • JVM的启动通过类加载开始

     • 执行

       • Java程序实际上就是JVM进程，JVM将编译后的字节码解释为机器指令通过操作系统交给计算机硬件执行，使用jps命令能查看当前计算机上执行的所有Java进程

     • 退出

       • 程序正常执行结束、程序执行过程中遇到异常或者错误异常终止、操作系统错误会导致虚拟机的退出

       • 进程中的某个线程调用Runtime类或者System类的exit方法或者Runtime的halt方法，且Java安全管理器允许的情况下，JVM进程也会终止

       • 调用JNI的API加载或者卸载JVM时，JVM进程也会终止

   • 常见JVM

     • Classic VM：1996年由Sun公司随着JDK1.0发布的世界上第一款商用JVM

       • 执行引擎中没有即时编译器，效率低下

       • 可以外挂JIT即时编译器，但是外挂JIT即时编译器无法使用解释器，虽然执行快，但是JVM启动时会编译大量代码造成JVM启动时长时间卡顿

       • 不能识别内存中的数据类型，通过句柄额外记录对象的内存地址来查找对象，不知道数据类型会带来一些麻烦，比如标记整理算法让JVM中的内存更紧凑会移动对象的位置，如果不知道内存存放的是数据本身还是引用会比较麻烦

     • Exact VM：JDK1.2由SUN公司发布

       • 提供准确式内存管理，虚拟机可以知道指定内存中的数据类型

       • 实现了解释器和即时编译器的混合工作

       • 还没投产就被HotSpot替换

     • HotSpot VM：HotSpot是一家名为Longview Technologies的小公司设计，97年被SUN公司收购，JDK1.3到现在一直是默认虚拟机

       • HotSpot的名字就指的是它的热点代码探测技术，占有绝对的市场地位，不管是openJDK还是oracleJDK都用的是HotSpot虚拟机

       • 方法区是HotSpot独有的，像J9、JRockit都没有方法区

     • JRockit VM：BEA公司发布，后被Oracle收购

       • JRockit VM专注于服务器端应用，不关注程序启动速度，关注程序的响应时间，因此JRockit VM内部没有解释器，全部代码都靠即时编译器编译；大量行业基准测试显示JRockit虚拟机是世界上最快的JVM，没有之一；提供毫秒甚至微秒级的响应，在延迟敏感型场景应用广泛

       • JRockit的Mission Control套件比较有用，被Oracle于JDK8整合到HotSpot中形成了现在的JMC，具体分成了内存泄漏检测器、JVM的运行时分析器和管理控制台三个独立应用程序，JMC的主要功能就是监控JVM的内存泄漏；

     • J9 VM：IBM发布

       • 市场定位和HotSpot接近，作为服务端、桌面、嵌入式等多用途VM，广泛用于IBM的各种Java产品

       • 在IBM自家产品上测试速度世界最快，但是通用性和其他产品上的性能比不上JRockit，而且在windows场景下使用Bug很多

       • 2017年，IBM开源J9 VM命名为OpenJ9，交给Eclipse基金会管理

     • CDC/CLDC：oracle在Java ME方向发布的两款虚拟机

       • 诺基亚时代的塞班系统，游戏和应用程序就是用Java ME产品线开发，现在手机被Android和IOS二分天下，Java ME几乎已经失去移动端市场、CLDC的KVM产品因为简单、轻量和高度可移植在更低端设备比如智能控制器、传感器和老年机上还在使用

     • TaobaoJVM：由AliJVM团队基于HotSpot深度定制开源的服务器版JVM

       • 使用GCIH技术将生命周期较长的Java对象从堆空间移到堆外，降低了GC的频率并且实现GCIH中的对象在多个JVM进程中共享

       • 使用crc32指令降低对JNI的调用开销

       • 提供针对大数据场景的ZenGC

       • Taobao JVM在阿里产品上性能高，在硬件上严重依赖Intel的CPU，损失兼容性，淘宝、天猫的产品全都把Oracle的JVM替换成了Taobao JVM

     • Dalvik VM：由谷歌发布应用于Android系统的虚拟机，没有遵循Java虚拟机规范，不能称为Java虚拟机，在Android2.2提供了即时编译器

       • Android5.0以前使用的Dalvik VM，此后替换为支持提前编译技术[AOT]的ART VM

         • 提前编译指可以直接把源文件不经过字节码直接编译成机器指令，执行效率更高

       • 不能直接执行class格式的字节码文件，执行dex格式的文件，dex格式文件可以通过Class文件转化得到，使用Java语法编写应用程序，可以直接使用大部分Java API

         • 安卓应用程序都是以.apk结尾的文件，改成zip解压，里面有大量.dex为后缀的文件，就相当于Java中的.class文件

       • 采用基于寄存器的指令集架构，执行效率高，和硬件耦合度高

     • Graal VM：2018年oracle发布，在HotSpot基础上增强而成的跨语言全栈虚拟机，可以作为任何语言的运行平台

       • 支持不同语言中混用对方接口和对象

       • 原理是将语言的源代码编程成虚拟机能识别的类似字节码的中间语言格式，只有Graal VM取代HotSpot的希望是最大的

2. 简述JVM组成结构和各结构功能

   • JVM结构

     • 1️⃣：类加载子系统：字节码文件依次经过加载、链接和初始化三个环节被加载到JVM内存中在运行时数据区的方法区中生成Class实例

     • 2️⃣：运行时数据区：运行时数据区包含程序计数器、虚拟机栈、本地方法栈、堆区和方法区，方法区和堆多线程共享，虚拟机栈、本地方法栈和程序计数器都是每个线程独一份，运行时数据区对应类为单例Runtime类

       • PC寄存器也叫程序计数器区域：每个线程一份程序计数器

       • 虚拟机栈区域：每个线程一份虚拟机栈，虚拟机栈的基本单元是栈帧[栈帧的内部结构分为局部/本地变量表、操作数栈、动态链接、方法返回地址]

       • 本地方法栈：本地C类库的方法调用执行栈

       • 堆区：Java中创建的对象主体都分配在堆区，JVM中内存最大的一块空间，GC重点考虑的一块空间，堆区也是多线程共享的资源

       • 方法区：方法区主要存放类信息、常量、域信息、方法信息；方法区是HotSpot虚拟机独有；JDK7以前方法区的落地实现叫永久代，JDK7以后叫元空间[永久代和元空间都是方法区的落地实现]

     • 3️⃣：执行引擎：执行引擎包含解释器、JIT即时编译器和垃圾回收器，负责将字节码指令翻译成机器指令供CPU执行

       • 每当执行完一条指令后程序计数器会更新下一条指令地址，执行引擎从程序计数器获取下一条指令；通过局部变量表中的对象引用定位堆中的对象实例；通过对象头的类型指针[也叫元数据指针]定位当前对象的类元数据

       • JIT即时编译器将反复执行的热点代码专门编译成机器指令并缓存在方法区方便解释器解释运行的时候直接调用

       • 执行引擎形象解释就是两种语言之间的翻译官

       • 所有JVM的执行引擎输入的都是字节码二进制流，处理过程是字节码的解析执行过程，输出执行结果

       • 大部分程序转换为物理机或者虚拟机执行的机器指令前，需要经过下面两条路径，其中程序源码--词法分析--单词流--语法分析--抽象语法树由Javac即前端编译器完成，形成抽象语法树以后会遍历语法树形成线性的字节码指令流，优化器--中间代码--生成器--目标代码是传统编译原理中程序代码到目标机器代码的生成过程，体现Java半编译型半解释型语言的半编译型；指令流--解释器--解释执行是逐行翻译解释执行的过程，体现Java半解释型半编译型语言的半解释型，Java半编译型半解释型语言的根本原因是字节码交给操作系统和CPU执行时既可以使用解释器，也可以使用即时编译器；Java一开始没有即时编译器因此最开始就只是解释型语言，后来发展出了可以根据字节码直接生成本地机器代码的即时编译器可以在方法区缓存被翻译的本地代码方便某段代码被频繁调用直接使用缓存的机器指令而无需再被解释器解释翻译，JVM执行Java代码时通常都会将解释执行与编译执行二者结合起来进行

         • 前端编译器即Java源码级编译器对代码的处理流程：源代码--词法分析器--Token流--语法分析器--语法树/抽象语法树--语义分析器--注解抽象语法树--字节码生成器--JVM字节码，这部分和JVM没有关系

         • JVM的执行引擎对JVM的字节码处理流程：

           • JVM字节码--机器无关优化--中间代码--机器相关优化--中间代码--寄存器分配器--中间代码--目标代码生成器--目标代码，由JIT即时编译器负责

           • JVM字节码交由字节码解释器逐行解释执行

       • 解释器：对应解释流程指令流--解释器--解释执行，负责根据预定义的规范将字节码指令逐条翻译为所在平台的本地机器指令执行

         • 一条字节码指令被解释执行完毕后，解释器再根据程序计数器中记录的下一条等待被执行的字节码指令执行解释操作

         • 古老的字节码解释器：就是将字节码逐条翻译成字节码指令并执行，效率非常低

         • 现在普遍使用的模板解释器：将每条字节码和一个模板函数关联在一起，通过模板函数直接产生当前字节码执行时的机器码，显著提高解释器的性能

         • 不管使用字节码解释器还是模板解释器凡是基于解释器执行都认为是低效的代名词，也是这个原因被C/C++程序员调侃，很多语言都有解释器，包括C和C++后面也补充了解释器，但是只有解释器就会成为低效的代名词；JVM提供及时编译器避免函数被解释执行，将整个函数体编译成机器码并缓存起来，再想执行这部分代码直接使用已经编译好的机器码，通过这种方式大幅提高程序的执行效率，避免冗余的将源码先编译成汇编语言，再将汇编语言汇编成机器语言的过程

         • 解释器的优势是JVM一启动就能直接拿着字节码开始逐行执行，但是JIT编译器需要先把一定范围的字节码全部翻译成机器指令以后才能执行，解释器启动快，单条字节码执行慢；JIT编译器要先编译再执行，启动慢，单条字节码执行快

       • JIT即时编译器Just In Time Compiler：对应编译流程优化器--中间代码--生成器--目标代码，将字节码指令编译成本地机器平台相关的机器指令并缓存起来，并不像解释器一样立即执行

         • 典型优势就是速度快，特别是代码大量复用的场景，就像是提前把菜切好，炒菜的时候不需要处理菜直接用，最重要的是超过的菜还可以复用

         • 编译器可以指前端编译器也可以指后端编译器，前端编译器负责将.java文件编译成.class文件，后端运行期编译器就是JIT即时编译器，负责将字节码转变成汇编再转变成机器码；典型的前端编译器比如JDK中的Javac、Eclipse JDT中使用自己研发的增量式编译器ECJ；典型的JIT编译器比如HotSpot中的C1、C2编译器；此外编译器还可以指静态提前编译器AOT编译器[Ahead of Time Compiler]，这是java发展的一个趋势

           • 查了一下java常规编译过程不直接设计汇编，AOT编译器内部可能涉及汇编的生成和优化

         • JIT编译器会根据代码被调用执行的频率判断字节码是否为热点代码，将热点代码进行即时编译

           • 热点代码：被多次调用的一个方法，或者一个方法体内循环次数较多的循环体都可以成为热点代码

           • 栈上替换：这种在方法执行过程中对热点代码的编译方式被称为栈上替换，也称为OSR[On Stack Replacement]编译

           • HotSpot采用基于计数器的任店探测方式来探测热点代码，HotSpot会为每个方法都建立方法调用计数器和回边计数器两个计数器；方法调用计数器统计方法的调用次数，回边计数器统计循环体执行的循环次数

             • 方法调用计数器在Client模式下的默认阈值为1500次，Server模式下的默认阈值为10000次，只要超过该阈值就会成为热点代码触发JIT编译，该阈值可以通过JVM参数-XX:CompileThreshold设置

               • 方法调用时会首先检查当前方法是否已经被JIT编译过，已经被编译过会直接调用编译后的机器码直接执行，如果还没有被编译过让方法调用计数器加1，检查计数是否超过阈值，没超过由解释器解释执行，超过向JIT编译器提交编译请求，编译缓存到方法区以后再被调用执行

               • 方法调用计数器统计的是一段时间之内方法被调用的次数，超过一定时间调用次数还没有达到阈值方法调用计数器会减少到原计数的一半，该过程称为方法调用计数器的热度衰减，该时间称为当前方法统计的半衰周期；可以通过配置JVM参数-XX:-UseCounterDecay来关闭热度衰减，此时方法调用计数器统计的是方法被调用的累计绝对数，只要系统运行时间足够长，绝大部分方法都会被编译为本地方法；可以通过JVM参数-XX:CounterHalfLifeTime设置半衰周期的时间，默认单位为s

             • 回边计数器统计一个方法中循环体代码被执行的次数，回边指字节码中遇到控制流向已经被执行过的指令跳转的指令

               • 遇到回边指令时检查循环体是否已经被JIT编译过，如果已经编译过执行循环体已经被编译过的本地代码；如果没有编译过，会让回边计数器加1，判断两个计数器的和是否超过阈值，没有超过阈值由解释器解释字节码执行；超过提交OSR编译请求JIT编译循环体并缓存再调用机器指令执行

         • JVM运行时可以通过命令参数显式指定运行时只采用解释器执行还是只采用即时编译器执行

           • -Xint：只采用解释器模式执行程序，JVM工作在interpreted mode下

             • 一个简单的几条语句的循环体被执行100万次，纯使用解释器执行时间为6520ms

           • -Xcomp：只采用即时编译器模式执行程序，当即时编译出现问题解释器会介入执行，JVM工作在compoled mode下

             • 一个简单的几条语句的循环体被执行100万次，纯使用解释器执行时间为950ms

           • -Xmixed：采用解释器+即时编译器混合模式执行程序，JVM工作在mixed mode下

             • 一个简单的几条语句的循环体被执行100万次，纯使用解释器执行时间为936ms

         • JVM内嵌C1和C2两个JIT编译器，C1也叫Client Compiler，C2也叫Server Compiler，可以通过命令参数显式选择具体使用哪一种即时编译器，64位的操作系统只支持server版本，即使指定了-client也会忽略掉

           • -client：指定JVM运行在Client模式下，使用C1编译器

             • C1编译器对字节码的优化简单，编译速度快

             • C1的优化策略主要有方法内联、去虚拟化、冗余消除；

               • 方法内联：将引用的方法代码编译到引用点处，不再让每次方法的调用都创建栈帧，将所有该方法的调用都指向一块空间

               • 去虚拟化：对接口唯一的实现类进行内联

               • 冗余消除：将运行期间不执行的代码直接折叠掉

           • -server：指定JVM运行在Server模式下，使用C2编译器

             • C2编译器对字节码的优化更激进深入，编译耗时长，但是优化后的代码执行效率更高

             • C2的优化是基于逃逸分析的优化，包括标量替换、站上分配和同步消除

             • 但是Server模式下也不是只用C2不用C1，JVM采用分层编译策略，不开启性能监控的情况下程序使用C1编译进行简单优化，开启性能监控后使用C2根据性能监控信息进行激进优化，JDK7以后，Server模式默认就开启了分层编译策略即开启了性能监控；C2编译器启动时长比C1长，但是系统稳定后，C2编译器编译出来的代码执行速度远远快于C1编译器

         • 一般JIT编译出来的机器码性能比解释器高

         • JDK10开始HotSpot加入一个Graal即时编译器，对应有一个Graal VM，该编译器的编译效果已经赶上了C2编译器，目前还带实验标签，即不同的版本可能修改或者移除，带有一个实现标识，可以通过JVM参数-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler激活使用，Graal和C2并列的关系，Graal属于即时编译器

       • JDK9引入AOT静态提前编译器，AOT是和JIT并列的关系，是与即时编译对立的概念，Java9引入实验性的AOT编译工具jaotc，在用户运行程序前可以手动将字节码文件编译成.so文件，直接就将字节码编译成机器码

         • 优势是JVM在启动之前就将字节码预编译成二进制库，JVM可以直接加载预编译的二进制机器码直接执行，无需预热，启动就执行机器指令

         • 缺点是打破了Java的跨平台特性，同一份.so文件不能在不同硬件和操作系统上执行；丧失Java链接的动态性，运行前就需要明确所有的机器指令，JVM运行前需要明确所有的代码，失去Java的动态链接特性；目前AOT编译器仅支持Linux 64位

       • HotSpot采用解释器和即时编译器并存的架构，JVM运行时解释器和即时编译器相互协作，由HotSpot决定何时使用解释器，何时使用即时编译器

         • JRockit因为主攻服务端市场，服务端应用对启动时间不关注，重点关注响应时间，完全抛弃解释器的JRockit启动时也必须花费更长的时间来对字节码进行编译，但是换来了高效的执行性能

         • 客户端市场对启动时间也有一定的需求，比如IOS的启动时间快，图标一点就有反应，安卓虽然功能强大，但是很多时候点图标半天才有响应；因此对于看中启动时间的应用场景，需要采用解释器与编译器并存的架构来在启动时间和响应时间之间找一个适用于场景的平衡点

         • 解释器与即时编译器并存的架构在热机状态下相较于冷机状态能承受更大的负载，如果以热机状态的可承载流量进行切流，可能导致处于冷机状态下的服务器因为无法承载住流量而假死；典型的比如生产环境发布过程的分批发布，一般将正在运行的机器数量划分为N个批次，每次对其中一个批次的机器进行发布更新，一般每个批次的机器数最多站总集群的1/8；阿里有过一个案例，一程序员在发布平台填写总发布批数的时候因为认为热机状态下一半的机器就能承载当前负载，就选择了分两批发布，结果第一次成功更新后的JVM刚启动都是解释执行，还没有对热点代码进行统计和即时动态编译，停掉另一半的机器此时刚发布成功后的机器全部处于冷机状态，无法承载当前的流量，导致第一批发布成功的服务器全部宕机；

         • 此外，阿里的限流框架Sentinel对资源的流控规则也设计有预热模式，当系统流量长期处于低水位的情况下，流量突然增加直接把系统拉升到高水位也可能瞬间把系统压垮。预热模式在QPS超过某个阈值默认值为3的情况下通过限制通过的流量，让流量在一定时间内默认值是5s逐渐增加到预设的流量阈值上限的冷启动方式，给冷机一个预热的时间，避免冷机被突增的高流量压垮压垮。使用这种限流框架也能防范上述分批发布冷热机切换存在的风险

     • 4️⃣：本地方法接口：包括本地方法接口JNI和本地方法库，在Java核心API中有一些没有方法体被native关键字修饰的方法，这些方法就是本地方法，实际上这些方法有方法体，只是底层已经用C/C++实现了；使用native关键字修饰的Java方法就是本地方法；native关键字和abstract关键字不能共用；本地方法主要是为了在Java平台在某些场景下使用C/C++来完成这些任务

       • 本地方法存在的主要原因是与Java外的环境交互，和操作系统以及一些硬件交互时必须使用C/C++，本地方法提供由C/C++实现的接口来供Java直接调用，操作系统主要还是由C/C++编写的，JVM不是一个完整的操作系统，必须依赖于操作系统的支持，Java通过C实现的本地方法和操作系统进行交互，此外Java中的一些方法需要直接和操作系统打交道这些方法都是由C实现的[类似于老美制定的国际标准，完全不使用这套标准还是有一定困难的]

       • Sun的解释器是用C实现的，jre大部分是用Java实现的，部分方法是用C实现并植入JVM内部，在底层很多的本地方法都是由外部的动态链接库提供被JVM调用

       • 以前与硬件交互比如由Java驱动打印机或者管理生产设备还需要用户编写本地方法，现在随着Java的发展，这种现象已经很少见了

     

3. JVM内存区域解析[内存区域就是运行时数据区，其中最重要的是虚拟机栈、堆和方法区]

   • 线程：线程是一个程序的运行单元，操作系统中有很多进程，单个进程中有很多线程，JVM中每个线程对象都和操作系统的本地线程存在一一对应关系；Java线程准备好执行[准备过程是准备线程对应的程序计数器、虚拟机栈、本地方法栈等]调用start方法后本地线程才会创建，本地线程创建并初始化成功后，操作系统就会调用Java线程中的run方法，Java线程执行结束后本地线程也会对应回收，如果Java线程出现异常Java线程会直接结束，本地线程还会决定JVM进程是否终止，判断依据是判断当前线程是否JVM进程的最后一个用户线程

     • HotSpot VM后台运行的守护线程主要有以下几类[通过jconsole可以查看这些线程]

       • 虚拟机线程：JVM运行达到安全点，虚拟机线程负责stop-the-world垃圾收集、线程栈收集、线程挂起以及偏向锁撤销

       • 周期任务线程：负责周期性任务的调度执行

       • GC线程：专门对JVM中不同类型的垃圾进行回收

       • 编译线程：将字节码编译成本地机器指令

       • 信号调度线程：接收信号并发送给JVM，JVM通过该线程对事件进行适当处理

   • 运行时数据区：运行时数据区包含程序计数器、虚拟机栈、本地方法栈、堆区和方法区，方法区和堆多线程共享，虚拟机栈、本地方法栈和程序计数器都是每个线程独一份，运行时数据区对应类为单例Runtime类

     • PC寄存器也叫程序计数器区域：程序计数器是从软件层面对CPU寄存器的抽象模拟[CPU只有把数据装载到寄存器中才能运行]，也被称为程序钩子

       • 功能是存储虚拟机栈中栈帧[栈帧就是线程执行的当前方法]的操作数栈中的下一条将被执行的指令的指令地址/偏移地址，执行引擎根据该内存地址去虚拟机栈的局部变量表和操作数栈读取下一条字节码指令；如果当前线程正在执行本地C类库方法，程序计数器的值为undefined

         • 注意后面又变了，老师和《深入理解Java虚拟机》中都说程序计数器记录的是当前正在被执行指令的指令地址，弹幕说操作系统中CPU里面的程序计数器指向的是下一条指令，JVM规范中明确指出这里的程序计数器指向的是当前正在被执行的指令

       • 每个线程一份程序计数器，生命周期与线程生命周期保持一致

       • PC寄存器没有垃圾回收的概念，也不会发生OOM内存溢出风险；虚拟机栈和本地方法栈没有垃圾回收，但是有可能会发生OOM风险；堆区和方法区有垃圾回收也可能发生OOM风险

     • 虚拟机栈区域：每个线程一份虚拟机栈，虚拟机栈的基本单元是栈帧[栈帧的内部结构分为局部/本地变量表、操作数栈、动态链接、方法返回地址]，每个栈帧对应一个方法

       • 指令集架构模型[有基于栈的指令集架构和基于寄存器的两种指令集架构]

         • 基于栈的指令集架构

           • 每执行一个方法就对方法做一次栈帧的入栈操作，方法执行完以后做一次栈帧的出栈操作

             • 基于栈的指令集架构一般都是零地址指令

             • 基于栈的字节码指令以每八位单字节的方式对齐，基于寄存器的指令以十六位双字节的方式对齐；单个指令字节数更小，总的指令数量更多

           • 特点[跨平台、指令集以零地址指令为主，单条指令占用空间小、编译器容易实现，缺点是基于内存相对性能不高，同样的功能需要更多的指令]

         • 基于寄存器的指令集架构

           • x86的二进制指令集和传统PC以及安卓的Davlik虚拟机都是基于寄存器的指令集架构

           • 特点[基于CPU高速缓冲区性能高，与硬件耦合度高可移植性差，指令集以一、二、三地址指令为主，单条指令占用空间大，但同样功能需要的指令数更少]

       • 堆和栈的区别

         • 栈是运行时的单位解决程序如何执行的问题、堆是存储的单位解决数据放在哪儿怎么放的问题[也不绝对，对象在堆中，基本数据类型的局部变量还是在栈中，对象作为局部变量栈中只是存放的对象引用而不是对象本身]

         • 虚拟机栈主管Java程序的运行，保存方法的局部变量、部分结果，参与方法的调用和返回

         • 栈的特点

           • 栈是仅次于程序计数器的快速分配存储方式，只针对栈顶对栈帧压栈出栈，操作简洁；因为栈的工作特性也不存在垃圾回收问题，可能存在OOM

       • 虚拟机栈[早期叫Java栈]在每个线程创建时都会创建一个私有的虚拟机栈，虚拟机栈的基本单元是栈帧，一个栈帧对应一次Java方法的调用，虚拟机栈生命周期与线程一致

         • 如果在线程创建时指定了虚拟机栈的容量，如果线程实际分配的栈容量超过虚拟机栈的容量最大值，Java虚拟机会抛出一个StackOverflowError异常

         • 如果虚拟机栈的容量设置为可动态扩展，只有在虚拟机栈尝试扩展时无法申请到足够内存或者创建新线程时没有内存去创建虚拟机栈时，虚拟机会抛出OutOfMemoryError异常

         • 虚拟机栈的大小可以通过虚拟机系统参数VM options指定为-Xss256k来设置，默认虚拟机栈的大小约1M，要避免虚拟机栈的容量大小低于单个线程运行需要的容量，否则会报栈溢出异常，但是虚拟机栈可以动态扩展，这点没有考虑进来

       • 虚拟机栈结构

         • 虚拟机栈的基本单位是栈帧，一个栈帧对应一个方法，栈帧维护方法执行期间的各种数据信息，虚拟机栈对栈帧压栈和出栈

           • 一个活动线程一个时间点上只有栈顶栈帧是活动有效的，称为当前栈帧；当前栈帧对应方法称为当前方法；定义该方法的类称为当前类

           • 执行引擎只运行当前栈帧中的字节码指令，程序计数器中存储的也是当前栈帧中的指令地址

           • 当前方法返回时，当前栈帧会将当前方法的恶之星结果返回给前一个栈帧

           • Java方法有两种返回函数的方式，一种是正常的函数返回，一种是抛出未被处理的异常，两种方式都会使当前栈帧被弹出

       • 栈帧结构

         • 栈帧由局部变量表、操作数栈[表达式栈]、动态链接[也称指向运行时常量池的方法引用]、方法返回地址[也称方法正常或异常退出的定义]、一些附加信息五部分组成，重点是局部变量表和操作数栈[栈帧的大小主要就取决于局部变量表和操作数栈的大小]，动态链接、方法返回地址和一些附加信息也被称为帧数据区

         • 局部变量表：局部变量表是一个数字数组，存储方法参数和定义在方法体中的局部变量，存储的数据类型为基本数据类型、对象引用和方法返回值地址，存储的数据主要是非静态方法的this指针、形参、方法内部定义的局部变量值，注意不是变量名

           • 基本数据类型中byte、short、long、int、double、float本身就是数字，char也有对应的ASCII码或Unicode码，存储前会被转换为int，boolean存储前也会被转成int，八种数据类型都可以用数字表示

           • 局部变量表线程私有，不存在数据安全问题

           • 一个方法的局部变量表的容量在编译阶段就确定了，保存在方法的Code属性的maximum local variables属性中，Code属性中的Code length表示方法赌赢字节码的指令行数，方法运行期间不会改变局部变量表的大小；通过javap指令和jclasslib插件都能查看一个类中所有方法的局部变量表信息和相应的作用字节码范围，局部变量表中的变量按照方法中的声明顺序排列

           • 局部变量表的基本单位是变量槽Slot，占32个比特位的数据类型即除long和double的其他数据类型包括对象引用只占一个Slot，long和double占用两个Slot，即一个Slot占32个比特位四个字节；使用变量起始位置的索引对变量进行引用

           • 实例方法和构造方法中可以调用变量this指代当前对象，这是因为实例方法和构造方法在创建时，当前对象的引用this会存放在局部变量表的第一个变量槽中，而静态方法的局部变量表中没有该操作，因此静态方法中不允许使用this

           • 方法中没有使用变量接受一个有返回值的被调用方法执行结果，当前方法的局部变量表中不会为被调用方法的返回值分配空间

           • 一张局部变量表中的变量槽中的变量如果作用域比方法的作用域小，在作用域后面声明的局部变量会在变量槽失效后占用该变量槽来节省空间，这中占用关系在编译时就决定好了

           • 局部变量表中的变量是垃圾回收的根节点GC Roots，只要被局部变量表直接或间接引用的对象都不会被回收，因此局部变量表也是性能调优重点关心的区域

           • 方法调用时形参的传参就是通过局部变量表来进行传递的

         • 操作数栈：也叫表达式栈，操作数栈根据字节码指令被压栈或者出栈字节码指令操作的数据，JVM的执行引用是基于操作数栈的执行引擎，操作数栈管理字节码执行过程中的所有数据，此外执行引擎还会将字节码指令翻译成机器指令结合操作数栈的数据交给CPU执行，并将CPU的执行结果再存入操作数栈中；操作数栈用于保存计算过程的中间结果，同时作为计算过程中变量的临时存储空间；操作数栈的作用是存放字节码指令的操作数和返回结果；执行指令前，JVM会将指令的操作数压入操作数栈，执行时将指令需要的一个或多个操作数弹出，指令执行结束后将执行结果重新压入栈中；操作数栈中弹栈压栈的是变量值

           • 操作数栈在栈帧创建时一同创建，操作数栈是一个容量确定的数组，具体容量在编译时就会被定义，通过方法的Code属性中的max_stack属性值能查到操作数栈的具体容量；对局部变量初始化时会先根据字节码指令将数据存入操作数栈，再从操作数栈将数据出栈存入局部变量表；对数据进行运算会先从局部变量表将数据压栈到操作数栈，再从操作数栈弹栈交给CPU执行，将执行结果压栈到操作数栈，再从操作数栈弹栈存入局部变量表

           • long和double类型的数据占两个栈单位深度，此外其他类型32位占一个栈单位深度；byte、short、char、boolean都会以int类型来保存

           • 如果被调用的方法有返回值，被调用方法返回后返回值会从上一个栈帧的操作数栈弹栈然后被直接压入当前栈帧的操作数栈中

           • 栈顶缓存技术[ToS]：因为频繁的入栈出栈操作导致更多的指令分派和内存读写次数从而降低程序的执行速度，HotSpot VM的设计者提出栈顶缓存技术，原理是将栈顶元素全部缓存在物理CPU寄存器中，减少数据的频繁入栈出栈操作，让CPU直接操作寄存器中缓存的数据，减少压栈弹栈次数

         • 动态链接：动态链接保存着当前栈帧指向方法区中运行时常量池中对应方法的符号引用，该符号引用的目的是为了让当前方法的代码能实现动态链接，动态链接对应静态解析，下面主要介绍方法调用

           • Java源文件中的所有变量和方法引用在被变成字节码时会被编译成符号引用保存在字节码文件的常量池中，字节码文件中专门有一个区域称为常量池，字节码文件被加载到方法区以后常量池对应的是运行时常量池，返回值为空这个空值也存在于常量池中，凡是返回空参的方法都会引用该常量池中的空参；类变量比如int类型对应的常量I也会存在常量池中，符号引用就是字节码文件常量池中的#数字的标识，符号引用可以指向一个常量本身也可以指向其他常量的符号引用，常量池就是为了提供符号和常量，节省资源，使用的时候直接通过符号来识别具体的资源并进行调用

           • 字节码文件将类用到的类、类中定义的方法、类变量、字符串等存入常量池并生成对应的符号引用，字节码指令通过符号引用在常量池中找到对应的信息来进行使用，比如在一个方法中描述调用了另外的方法，这是为了同一份资源的共用，节省资源，同时通过方法引用实现子类调用父类的方法引用来实现多态的设计思想

           • 静态链接：字节码文件装载到JVM时如果其中的具体方法在编译阶段已知且运行期间保持不变，在编译期间就能确定符号引用和直接引用的对应关系就称为静态链接

             • 早期绑定：在编译期间就能确定被调用的具体方法内容，此时符号引用就能直接指向方法、字段或者类的直接引用，此时就会使用静态链接的方式，典型场景就是不使用多态或者super.eat()指定调用父类中的eat()方法，指定调用父类的构造方法super()，单参构造通过this()调用无参构造

             • 面向过程的语言只有早期绑定、面向对应的语言都支持封装、继承、多态，都同时具备早期绑定和晚期绑定两种方式；Java中任何一个方法都可以拥有C++中虚函数的特征，即多态通过父类型引用指向子类型实例来实现对子实例方法的调用，如果不希望某个方法拥有虚函数的特征可以使用final关键字来进行标记，即多态中对final修饰方法的调用还是调用的父类的对应方法引用，对应的final修饰的方法不能被子类重写，这是对多态的理解

             • 非虚方法：编译期间就确定了被调用方法的具体版本，且运行时不会发生改变的方法，静态方法、私有方法、final修饰方法、实例构造器、通过super调用父类方法都是非虚方法，除了这五种情况剩下的方法都是虚方法；字节码中invokestatic和invokespecial指令是调用非虚方法的指令，invokestatic调用静态方法，invokespecial调用构造器、私有或者调用父类方法；invokevirtual和invokeinterface调用所有虚方法以及final修饰的非虚方法，final修饰非虚方是通过invokevirtual调用的；此外还有一个invokedynamic指令可以动态解析出需要调用的方法，该指令在jdk7引入，目的是为了实现动态类型语言，jdk7需要使用ASM字节码工具来生成invokedynamic指令，jdk8的Lambda表达式让该指令可以直接在方法执行过程中动态生成

               • 静态类型语言：Java语言本身是静态类型的语言，有了invokedynamic指令后Java语言就具备了动态类型语言的特性，在编译期间就对数据类型检查的语言是静态类型语言，如果数据字面值不满足变量的指定类型编译就会报错，静态类型语言判断变量自身的类型信息

               • 动态类型语言：在运行期间对数据类型检查的语言是动态类型语言，像JS和Python就是动态类型语言，动态类型语言判断的额是变量值的类型信息，变量没有类型信息、变量值才有类型信息；只能根据变量值才能确定一个变量是什么类型的，虚拟机引入该invokedynamic是为了在JVM上支持动态类型语言的运行

           • 动态链接：方法只能在程序运行期间将符号引用转换成直接引用称为动态链接

             • 晚期绑定：编译期间不能确定被调用的具体方法，只能在运行期间根据实际类型确定被调用的具体方法，就会通过动态链接的方式来实现符号引用指向直接引用，典型场景就是多态[子类对象多态性的前提是类的继承关系和方法的重写]

           • 方法重写的本质：通过方法调用的字节码指令将执行对象实例的实际类型压栈到操作数栈栈顶，通过该类型去常量池中找名字描述一致的方法，并进行权限校验，校验通过直接找到方法的直接引用，校验不通过抛出IllegalAccessError异常；按照继承关系从下往上依次对该类型的和各个父类进行上述常量池搜索和校验的过程直到找到具体的方法，如果遍历到最顶层的类或者接口还没有找到具体的方法就会抛出AbstractMethodError抽象方法异常；为了避免频繁动态分派在类的方法元数据中搜索合适的目标来提高性能，JVM在类的方法区建立一个虚方法表，虚方法表中存储着各个虚方法的实际入口，只要虚方法被动态分配一次，后续调用就能直接通过虚方法表找到对应的方法入口而不再需要进行搜索，虚方法表在类加载的链接环节的解析步骤被创建并开始初始化，类变量初始化完成后虚方法表也被初始化完毕，子类重写过的虚方法在虚方法表中执行子类自身的虚方法

         • 方法返回地址：方法返回地址保存调用当前方法的方法调用当前方法时的程序计数器的值，即调用当前方法的方法的下一条指令，正常执行结束的方法通过方法返回地址来确定上一个方法下一条应该被执行的指令；说白了就是退出当前方法前先将PC寄存器中的值设置为当前方法方法返回地址中的值，让当前线程去执行上一个方法的下一行代码

           • 特别注意异常退出当前方法通过异常表来确定上一个方法下一条应该被执行的指令

             • 异常表就是在指定字节码行号范围内出现的异常根据异常类型匹配执行指定异常对应字节码指令起始行号指令，异常表可以通过字节码中对应方法的Exception table来查询

           • 正常退出会给调用者返回当前方法的返回结果，但是异常退出不会给上层调用者返回任何结果，没有被处理的异常会被抛给上层调用者

           • 当前方法正常调用完成后需要根据返回值的实际数据类型来确定使用哪一个返回指令，boolean、byte、char、short、int对应的返回指令为ireturn，long对应指令为lreturn，float对应指令为freturn、double对应指令为dreturn，引用类型对应指令为areturn，void、构造器、类和接口的<clinit>()方法对应的指令为return

         • 一些附加信息

           • 附加信息不同的JVM实现允许携带的附加信息不同，比如设置对程序调试提供支持的信息

     • 本地方法栈：本地C类库的方法调用执行栈，虚拟机栈管理Java方法的调用，本地方法栈管理本地方法的调用，本地方法指被Java语言调用用C实现的方法

       • 本地方法栈是线程私有的，本地方法栈也可以设置固定容量或者设置为可动态扩展内存，同样固定容量实际使用量大于固定容量抛栈溢出异常，动态扩展容量没有足够内存扩容或者创建本地方栈抛内存溢出异常

       • Java调用本地方法时会将本地方法以栈帧的形式压入本地方法栈，通过动态链接的方式由执行引擎调用本地方法库

       • 本地方法可以直接通过本地方法接口访问虚拟机内部的运行时数据区，还可以直接使用本地处理器中的寄存器和随意使用本地内存

       • 不是所有的JVM都支持本地方法，JVM规范没有要求本地方法栈，HotSpot虚拟机将本地方法栈和虚拟机栈合二为一，直接通过动态链接的方式在本地方法库找到本地方法由执行引擎来执行

     • 堆区：Java中创建的对象主体都分配在堆区，JVM中内存最大的一块空间，GC重点考虑的一块空间，堆区也是多线程共享的资源，堆区分为新生代和老年代

       • 概念

         • 一个JVM实例[一个JVM进程只能运行一个主方法]只有一个堆内存，堆是Java内存管理的核心区域；JVM启动时通过引导类加载器创建运行时数据区的同时创建堆区，堆一创建容量就确定了，堆空间容量可以通过参数-Xms10m -Xmx10m调节即初始堆空间和最大堆空间都是10M[参数在执行java指令运行字节码的时候指定]，堆是JVM中最大和最重要的一块内存空间

         • 堆可以处于物理上不连续逻辑上连续的内存空间，不连续的物理内存可以通过映射表在逻辑上视为连续的一块内存

         • 堆空间被所有线程共享，但是每个线程还可以在堆空间开辟线程私有缓冲区即TLAB，多线程并发为了共享数据的安全性需要同步保证对共享数据操作的原子性，会降低系统的性能，TLAB在保证数据安全性的同时保证线程并发性能

         • 几乎所有的对象实例和数组都应该分配在堆上，JVM为了提高性能，引入了逃逸分析，如果方法创建的对象没有发生逃逸可以把对象分配在虚拟机栈上

         • 对象使用完毕不会马上从堆中移除，仅在垃圾回收阶段才会被移除，这是为了避免频繁GC影响用户线程的执行降低系统性能[GC会暂停JVM中的所有线程]；堆是垃圾回收的重点区域，在大内存对象和频繁垃圾回收的情况下垃圾回收会成为系统性能的瓶颈

         • 创建对象的字节码指令是new，创建数组的字节码指令是newarray

         • 堆区通过系统参数-Xms或-XX:InitialHeapSize设置堆区的起始内存，通过系统参数-Xmx或-XX:MaxHeapSize设置堆区的最大内存

           • -X表示这是jvm的运行参数，ms表示memory start初始内存大小，默认单位是字节数，k或者K表示KB，m或者M表示MB

           • 默认情况下，初始内存大小是物理电脑内存大小的1/64，最大内存为物理电脑内存大小的1/4；通常-Xms和-Xmx会配置相同的值，目的是为了在垃圾回收清理完堆区后不需要重新计算堆区的大小[因为最大容量和初始容量不同系统每次垃圾回收后都会重新计算应该给堆区分配多少内存，消耗系统性能]，提高系统性能；注意这个物理内存是可用内存，实际上操作系统还会使用约几百M的内存，这部分内存对用户来说是不可用的

           • 通过Runtime.getRuntime().totalMemory()或者Runtime.getRuntime().maxMemory()可以分别获取当前虚拟机的堆内存容量和最大堆内存容量

           • jstat -gc 进程号命令可以查看JVM在GC时的统计信息，其中OC是老年代的总堆内存、OU是老年代已经使用了的内存，对应的EC、S0C、S1C分别对应伊甸园区、幸存者0区、幸存者1区的内存

           • 注意幸存者0区和幸存者1区只能二选一使用，始终有一个空间是空的，JVM统计堆的总大小的时候只会总计其中一个幸存者区的大小，因此实际上堆区的大小比JVM统计的值要略大

         • 在jvisualVM上的抽样器选项卡的抽样属性的内存中能看到每种类型数据占用的容量

       • 堆内存细分

         • 现代垃圾收集器大部分基于分代收集理论设计，对应分代收集算法

           • 分代的唯一理由就是优化GC性能，如果没有分代，每次垃圾回收都要判断所有的对象是否需要垃圾回收，而不是降低对长生命周期对象垃圾回收垃圾判定的频率，就会导致每次垃圾回收的效率都会越来越低

         • JDK7以前将堆逻辑上分为新生代、老年代和永久代；JDK8以后将堆逻辑上分为新生代、老年代和元空间

           • 新生代也叫新生区、年轻代；老年代也叫养老区、老年区

           • 新生代分为伊甸园区、幸存者0区、幸存者1区[幸存者区也叫from区或to区]三部分，注意每个幸存者区都可能是from区和to区

           • 注意逻辑上的堆空间包含新生代、老年代和元空间，实际上的堆空间容量只包含新生代和老年代两部分的总容量

           • 通过系统参数-XX:+PrintGCDetails能在程序运行的时候打印当前JVM垃圾回收器的细节，该参数配置以后在程序运行结束后才会在控制台打印，会展示堆区和方法区的容量细节

           • JDK8永久代变化为元空间也引起了Stringtable字符串常量池和静态域结构的变化

         • Java对象可能是瞬时对象也可能极端情况下生命周期和JVM一样长，像连接对象的生命周期就会长一些；

           • 为了避免每次GC都判断生命周期很长的对象是否进行回收，将这些生命周期可能很长的对象放入老年代来降低GC判断的频率

           • 几乎所有对象最初都在伊甸园区创建，一定条件下伊甸园区的对象还没有销毁就存入幸存者0或者幸存者1区；一定条件下幸存者区的对象还没有销毁就存入老年代

             • 只有创建的对象特别大，大到伊甸园区都放不下，此时就会直接在老年代创建该对象

             • IBM公司专门研究表明新生代中80%左右的Java对象的销毁都在新生代进行

         • JVM参数-XX:NewRatio=2可以设置新生代老年代的内存比例，该参数示例表示新生代占1份，老年代是新生代的两倍，新生代占整个堆区的1/3，这也是JVM的默认配置，实际生产该参数一般不会调整，只有非常明确系统中很多对象的生命周期都很长才会将老年代的比例调大一些

           • jps指令和jstat指令配合或者使用jvisualvm都能查看堆区的细分区域大小

           • jinfo -flag NewRatio 进程号指令能查看指定进程JVM参数NewRatio的值

           • 可以通过JVM参数-Xmn设置新生代的最大内存大小，该参数优先级大于-XX:NewRatio=2，两者冲突的情况下会优先采用-Xmn的设置，总的堆容量减去新生代的容量得到老年代的容量

         • 默认情况下HotSpot虚拟机中，伊甸园区和两个幸存者区的内存空间占比JVM官方文档说是8:1:1，但实际上不是8:1:1，此外还可能受JVM的自适应机制影响，通过JVM参数-XX:-UseAdaptivePolicy可以关闭自适应机制[开启内存分配自适应还可能导致两个幸存者区不一样大]，-Use的-表示不使用，如果替换成+表示使用；但是实际配置关闭自适应机制以后没有实现对应效果还是原样；要想完全自定义伊甸园区和幸存者区的比例需要使用JVM参数-XX:SurvivorRatio=8来自定义设置伊甸园区是单个幸存者区容量的8倍

     • 方法区：方法区主要存放类元信息、常量池、域信息、方法元信息；方法区是HotSpot虚拟机独有；JDK7以前方法区的落地实现叫永久代，JDK7以后叫元空间[永久代和元空间都是方法区的落地实现]，此外方法区还缓存JIT即时编译产物

       • 方法区也是存在垃圾回收的，但是JVM规范并没有强制要求所有虚拟机都要实现方法区垃圾回收，元空间一般来说空间占用是比较稳定的，GC不像方法区那么频繁；方法区主要存放运行时常量池，类的属性和方法数据，方法和构造器的字节码[JDK8及以后运行时常量池移动到堆中了]，以及类或者对象实例初始化时使用到的特殊方法比如<clinit>方法或者<init>方法等

       • 方法区在运行时数据区创建时启动，在JVM进程结束时销毁，JVM规范指出将方法区逻辑上看做堆的一部分，但是具体的实现可以选择不对方法区进行垃圾回收和压缩。堆区是要求要垃圾回收，以及为了避免存储碎片的问题会对存储空间进行整理和压缩；JVM规范不限制方法区的位置和方法区的管理策略；方法区可以设置成固定大小，也可以在运行时动态的扩缩容，方法区的内存和堆一样不要求是物理上的连续空间；HotSpot的方法区还有一个别名叫非堆，目的就是要将方法区和堆分开，可以认为JVM规范逻辑上认为方法区是堆的一部分，但是实际的实现因为不进行GC和压缩，要把方法区和堆区分开

       • 方法区大小决定系统可以保存多少个类，如果系统定义的类太多，可能会导致方法区溢出跑OOM异常，方法区在JDK7及以前的实现叫永久代，JDK8以后叫元空间；默认加载的类就非常多，随便写一个简单的代码，加载的类的数量就能达到1674个左右，加载大量的第三方jar包比如Tomcat部署30到50个工程就可能出现方法区溢出的问题；大量地动态生成反射类也可能会造成类过多导致方法区溢出

       • JDK8中类的元数据存储在被称为元空间的本地内存[非JVM内存，就是本机的可用物理内存]中，方法区和永久代不能等价，BEA的JRockit和IBM的J9中不存在永久代的概念，JDK7以前永久代还是使用JVM的内存，可以通过参数-XX:MaxPermSize设置永久代的大小，JVM的内存空间有限，容易抛OOM异常，像JRockit和J9一样使用本地内存方法区的内存可以达到几个GB，不容易出现OOM；JRockit是世界上公认的速度最快的虚拟机，HotSpot和JRockit合并的时候内存不统一，采用了JRockit更好的方法区设计；元空间和永久代本质的区别就是元空间使用本地内存，永久代使用JVM内存，此外还更改了一些细节比如将运行时常量池和静态变量移动到堆空间

         • JDK7以前的版本可以通过-XX:PermSize来设置永久代的初始空间，默认是20.75MB；通过-XX:MaxPermSize来设定永久代的最大可分配空间，32位操作系统默认是64MB，64位操作系统默认是82MB，加载的类信息容量超过该最大可分配空间会抛OOM异常；这两个参数在JDK8中已经被废弃了，如果在8中主动设置在程序运行结束后会提示参数已移除

         • 元数据区大小可以使用参数-XX:MetaspaceSize和-XX:MaxMetaspaceSize指定，默认值和操作系统平台有关，windows平台默认情况下初始空间约21MB，最大可分配空间值为-1，表示没有限制，即以本地内存的最大值作为方法区的最大值

         • 一旦系统的方法区达到初始空间大小就会触发Full GC卸载没用的类，对应的类加载器被释放，然后根据GC释放的容量大小来决定方法区新的内存空间，如果释放的少，就适当的提高；如果释放的空间过多，则会适当降低该值；初始值太低会频繁触发Full GC，建议将方法区设置的尽量高一些

       • 虚拟机栈中存放对象的引用，引用指向堆空间中的对象实例，对象实例中存放了一个到对象类型数据的指针，指针指向创建对象实例的class对象

       • 方法区的演进

         • JDK1.6及以前经典方法区主要存储被虚拟机加载的类型信息[域信息、方法信息]、运行时常量池、静态变量、即时编译器编译后的代码缓存，06年建立OpenJDK的时候就有更改永久代的想法，Oracle在08年收购了JRockit虚拟机，在14年发布JDK8的时候将永久代移除，因为方法区的具体实现不受JVM规范约束，因此不同的Java虚拟机实现并不统一

         • JDK1.7将字符串常量池和静态变量从永久代移动到堆中，永久代字符串常量池存在运行时常量池中，后续只是将字符串常量池移到堆中，运行时常量池还是在永久代中

           • 将StringTable转移到堆空间的原因：Full GC只有在老年代空间不足，永久代空间不足时才会触发，这就导致字符串常量池的回收效率不高，开发中一般都会有大量的字符串被创建，如果字符串常量池的回收效率低，很容易就会导致永久代的内存不足；将字符串常量池放在堆中是为了即时回收常量池中的内存

           • 静态变量转移到堆中，注意静态变量的值如果是一个对象，该对象还是被创建在堆区，JDK1.6及以前静态变量对应对象创建在永久代中，对象的引用指向堆中的值对象，JDK9开始引入了一个监控JVM进程的jhsdb工具；通过Inspector可以查看class对象实例，发现静态变量随着Class对象存放在一起存储在堆区，只是类的元数据包含类的方法代码、变量名、方法名、访问权限、返回值等才是存放在方法区

           • 成员变量本身是随着创建的对象一起存放在堆区，局部变量本身存放在栈帧的局部变量表中，创建的对象存放在堆中；

         • JDK1.8及以后，废弃了永久代，将类型信息、字段、方法、常量保存到元空间

         • 使用元空间替换永久代的原因：

           • 实际生产中永久代的空间大小根据项目情况很容易发生变化，项目引入的Jar包过多，项目的功能点较多，都会动态增加系统需要加载的类数量，永久代受到JVM内存的限制很容易出现OOM错误，空间小也容易导致频繁Full GC，本地内存默认最大值为-1，即没有限制，物理内存足够就可以敞开用，还可以避免由方法区内存不足引起的频繁Full GC

           • 方法区的垃圾回收主要回收废弃的常量和不再使用的类，判断类不再进行使用是一个很复杂消耗很高的操作，对方法区的垃圾回收性能很低

         • JDK8以后运行时数据区变化不大，主要变化在执行引擎的GC垃圾回收器上

       • 方法区的内部结构

         • 方法区主要存储已经被虚拟机加载的类型信息[域信息、方法信息]、运行时常量池、静态变量、即时编译器编译后的代码缓存，JDK8以后JVM规范要求字符串常量池和静态变量转移到堆中，类型信息、字段、方法、常量保存在本地内存的元空间中

         • 类型信息

           • 类的全限定类名

           • 当前类的直接父类的全限定类名，接口和Object类没有父类

           • 类型的修饰符

           • 当前类实现的直接接口的有序列表、

           • 域信息

             • 域名称、域类型、域修饰符、域的声明顺序

           • 方法信息

             • 构造器

             • 方法名称、返回值类型、参数的个数和类型的有序列表、方法的修饰符、方法的字节码、操作数栈的深度、局部变量表的长度

           • 异常表

             • 如果方法有异常，会在异常表中记录每个异常处理的开始位置[try的下一行]、结束位置[整个try语句块的最后一行]，出现异常时的下一行即catch语句那行

         • 类变量

           • 静态变量和类关联在一起，随着类的加载而加载，逻辑上属于类数据，被所有实例对象共享，即使没有任何类实例被创建依然可以直接访问类变量[一个对应类型的空指针也可以直接访问指定的类变量而不会抛空指针异常]

           • 使用final修饰的类变量被称为全局常量，全局常量在编译期间就被赋值，类变量在类加载期间的链接环节的准备阶段才分配内存赋默认值，在类加载的初始化环节才显示赋值

         • 运行时常量池

           • 字节码文件中的常量池加载到方法区以后成为运行时常量池，常量池表包含了各种字面量以及对类型、域和方法的符号引用，符号引用的格式为#数字，常量池相当于一张表，用于存放编译期间生成的各种字面量和符号引用，虚拟机指令根据符号引用去常量表中找到要使用的类名、方法名、参数类型、字面值等数据

           • 每个类都会对应一个运行时常量池，类或者接口被加载到虚拟机以后就会创建维护一个对应的运行时常量池，池中的数据和数组一样通过索引进行访问，索引从01开始，到常量池数量减1结束；运行时常量池中存放明确的数字字面值，并将运行解析后才能获取的方法或者字段的真实引用替换原来的符号引用，因此运行时常量池相较于常量池因为动态替换符号引用具有动态性的特征，在类加载的解析阶段会替换一次，在程序执行过程中通过符号引用找到对应的类，但是发现类对象没有加载会加载对应的类并将符号引用替换成直接引用

           • 通过JVM参数-XX:+PrintStringTableStatistics能配置打印字符串常量池中的统计信息

       • 方法区的垃圾回收

         • JVM规范没有对方法区的实现做强制约束，一些简单的实现可以不对方法区进行垃圾回收以及碎片进行压缩管理；实际上也存在未实现或未完整实现方法区类型卸载的垃圾收集器比如JDK11的ZGC就不支持类卸载，但是HotSpot一直还是支持方法区的垃圾回收的

           • 这种不支持方法区类卸载的垃圾回收器性能也会更高一些

         • 方法区中类型的卸载条件非常苛刻，导致方法区的垃圾回收效果一般不咋明显；但是有时候方法区的垃圾回收又确实比较必要；以前Sun公司的Bug列表中很多严重的Bug就是由于低版本的HotSpot虚拟机未完全回收方法区导致的内存泄漏，就是不回收方法区还不行，但是回收大部分时间都做的无用工

           • 大量使用反射、动态代理、CGLib等字节码框架，动态生成JSP和OSGI这类频繁自定义类加载器的场景通常还确实需要JVM具备类型卸载能力来保证不会对方法区造成过大的内存压力

         • 方法区主要回收的是常量池中废弃的常量和不再使用的类，运行时常量池主要存放字面量和符号引用两大类常量；字面量主要包含文本字符串，被final修饰的常量值等；符号引用属于编译原理方面的概念，包含类和接口的全限定类名、字段的名称和描述符、方法的名称和描述符

           • 常量池的回收策略比较明确，主要常量没有被任何地方引用就可以被回收

           • 类的回收比较麻烦，判断一个类不再使用的条件很苛刻，需要同时满足以下三个条件才允许当前类被回收，但是也不是像对象一样没有引用了就必然被回收，

             • 该类的所有实例都已经被回收即堆中不存在该类及任何派生子类的实例，只要有一个实例存在，实例就会有一个指针指向当前类在方法区的类型信息

             • 加载该类的加载器已经被回收，类对象记录了当前类是被哪个类加载器加载的，类加载也记录了加载过具体哪些类，这个条件除非是精心设计的可替换类加载器场景比如OSGI和JSP的重加载，否则一般是很难达成的，注意类加载器加载的所有类都卸载的情况下类加载器也会销毁

             • 当前类的class对象没有在任何地方被引用过，即没有在任何地方使用反射来访问该类

4. 为什么要使用PC寄存器存储字节码指令地址呢？

   • 因为CPU不停切换执行各个线程来实现并行并发效果，当CPU切换回当前线程时需要明确从哪一条指令继续向下执行，JVM字节码解释器通过改变PC寄存器的值来明确将被执行的下一条字节码指令

5. PC寄存器为什么被设定为线程私有

   • 因为线程上下文切换需要记录当前线程正在执行的字节码指令地址，如果程序计数器被设定为共享的，当线程抢到CPU时间片后程序计数器中保存的线程状态信息会被其他线程覆盖导致当前线程的执行被其他线程干扰

6. 举例栈溢出情况

   • 虚拟机栈的容量如果是固定的随着方法调用不停压榨栈帧最后由于虚拟机栈容量不足抛出StackOverflowError异常，通过JVM参数-Xss可以设置栈的大小；如果虚拟机栈设置了可自动扩容最后由于没有内存无法扩容会抛出OutOfMemoryError异常

   • 只调整栈大小不一定能保证不会出现栈溢出，默认情况下虚拟机栈的大小约1M，不管虚拟机栈多大，错误死循环的递归调用一定会导致栈溢出，虚拟机栈不涉及垃圾回收问题

   • 虚拟机栈也不是越大越好，大了也可能只是延缓发生栈溢出的时间或者频率；而且太大都是无效空间反而会挤占其他内存空间

7. 方法中定义的局部变量是否都是线程安全的

   • StringBuffer中的所有方法都添加了synchronized同步锁，StringBuilder没有添加同步锁，局部变量

   • 引用数据类型也可能被多个线程访问因此局部变量不一定是线程安全的，要具体情况具体分析，始终保证单个线程对实例的原子性操作就是线程安全的

8. 简述一下永久代

   • 永久代是否会发生垃圾回收

   • 为什么使用元空间替换永久代

9. Eden和Survivor比例如何分配

   • JVM规范中指出默认情况下伊甸园区与单个幸存者区的比例是8:1，但实际上不是8:1:1，我的显示是6:1；关于这点网上有些帖子说还可能受JVM的自适应机制影响，通过JVM参数-XX:-UseAdaptivePolicy可以关闭自适应机制[开启内存分配自适应还可能导致两个幸存者区不一样大]，-Use的-表示不使用，如果替换成+表示使用；但是实际配置关闭自适应机制以后没有实现对应效果还是原样；要想完全自定义伊甸园区和幸存者区的比例需要使用JVM参数-XX:SurvivorRatio=8来自定义设置伊甸园区是单个幸存者区容量的8倍

10. HotSpot为什么要分为新生代和老年代

11. JVM内存模型，重点重排序， 内存屏障， happen-before， 主内存， 工作内存，直接内存

    • 直接内存：本地内存就是直接内存，JDK8以后的元空间就用的本地内存；直接内存是在Java堆外直接向系统申请的内存区间；直接内存来源于NIO，通过基于直接内存的DirectByteBuffer实现操作系统和JVM都能直接访问到一块内存地址减少一次用户态到内核态的转换，减少一次数据拷贝；NIO在JDK1.4被引入，在JDK1.7引入NIO2即AIO，同时还引入了Files和Path等对NIO增强的API，JVM没有权限释放直接内存，底层是依靠Unsafe的方法通过操作系统来释放的；访问物理内存上的文件使用直接内存比堆的速度更快，JVM进程代表的应用程序从JVM内存中读取数据，JVM内存中的数据需要从内核地址空间拷贝，内核地址空间的数据需要从物理磁盘上读取；通过JVM进程向磁盘写入数据时也需要先将数据写入到用户态即用户地址空间，然后将数据复制到内核态即本地物理空间的内存上，再由操作系统将数据写出到物理磁盘上；相较于JVM和操作系统都能访问的直接内存多了一次数据从用户态向内核态的拷贝，性能更低；直接内存的开辟回收成本高，直接内存不受JVM管理，监控管理起来有难度，dump文件也不会有相关记录；直接内存读写性能高，在频繁读写的场合下会更多的考虑使用直接内存；Java中使用直接内存比较多的就是元空间和NIO

      • 直接内存大小可以通过JVM参数MaxDirectMemorySize设置，如果不指定，默认与堆的最大值-Xmx的参数值一致；注意这里的直接内存大小不包括元空间，是JVM能通过比如NIO访问的直接内存大小，老师后来提到元数据区、直接内存是本地内存中互斥的两个部分，JVM进程占用的内存为堆内存加上元空间加上直接内存的总和

     

类加载

1. 类加载与类卸载过程

   • 概念：

     • 类加器子系统负责从文件系统或者网络中将一个或多个字节码文件以二进制流的方式加载到内存结构中初始化成一个或多个Class实例[元数据模板，通过元数据模板的构造器就能在堆空间中创建单个或多个对应类对象，通过Class对象的getClassLoader()方法可以获取负责该过程的类加载器对象，通过对象的getClass()方法能获取到对应的Class对象]，除了该Class实例外，方法区中还会存放运行时常量池信息[需要用的常量池加载到内存中就称为运行时常量池]，字符串字面值和数字常量

     • 字节码文件在文件头有一个特定的模数标识cafebaby，该模数会参与链接阶段的验证

     • 类加载器只负责字节码文件的加载，字节码文件是否可以被执行是由执行引擎决定的

     • 类加载包含加载、链接和初始化三个环节

   • 类加载过程

     • 当前类HelloLoader是否装载，已装载直接进入链接流程

     • 没有装载使用类加载器进行装载[自定义类使用应用类加载器装载]，如果字节码文件不是一个合法的字节码文件，类加载器加载的过程中会抛出异常，加载成功再内存中生成元数据模板即对应Class实例

     • 有了Class对象执行链接步骤

     • 初始化对象实例

     

      

   加载环节

   1. 加载过程：

      • 通过一个类的全限定类名从物理磁盘或者网络获取该类的二进制字节流

      • 将字节流代表的静态存储结构转化为方法区的运行时数据结构

      • 在内存中生成一个代表该类的java.lang.Class对象，该对象作为方法区中该类的各种数据访问入口

   2. 被加载的字节码文件来源

      • 本地文件系统

      • 从网络中获取，典型应用就是Web Applet

      • 从zip压缩包中读取，这也是jar、war压缩格式的读取基础[jar包war包解压后都是字节码文件]

      • 运行时通过计算生成，典型应用就是动态代理技术java.lang.reflect.Proxy

      • 由其他文件生成，典型应用就是JSP应用

      • 从专有数据库中提取[比较少见]

      • 从加密文件中解密获取，是一种防止字节码文件被反编译的保护措施[比如将.apk格式替换成.zip格式解压就能获取字节码文件，对字节码文件进行反编译就能盗版一个软件或者寻找软件漏洞，因此一般都会对字节码文件进行加密防止我们这种人反编译字节码，真正运行的时候会自动对加密后的字节码文件进行一个解密操作]

    

   链接环节

   1. 链接过程

      • 验证：通过验证文件格式、元数据验证、字节码验证、符号引用验证四种验证确保Class文件的字节流信息符合当前虚拟机要求，保证被加载类正确且不会危害虚拟机自身安全，验证不通过报verify error

      • 准备：在方法区中为所有类变量[类变量是被static修饰的变量]分配内存，将所有非常量的类变量设置为默认初始值即零值，显示初始化的类变量在初始化环节设置指定值；但是注意被final修饰的类变量即常量准备阶段会直接赋值指定值；准备阶段不会分配初始化实例变量，实例变量随对象创建一起被分配到堆区

      • 解析：将常量池内的类、方法、接口、属性的符号引用转换为直接引用[符号引用理解为占位符，直接引用是目标对象的内存地址，这一步就是建立虚方法表的过程]，解析一般会在初始化环节完成后再执行

   初始化环节

   1. 初始化环节就是执行类构造器方法<clinit>()的过程，这个<clinit>()方法不同于类的构造器，是javac编译器收集类中所有类变量的赋值动作和静态代码块中的语句合并自动得到对应字节码的<clinit>方法[<clinit>方法在字节码文件的Methods下的<clinit>下的Code可以看到对应的赋值语句和静态代码快语句对应的字节码指令]

      • 类在第一次执行实例化对象时才会执行初始化环节，暂时不清楚整个类加载过程是否在第一次实例化对象时才会执行，因此一个类的静态代码块只有在第一次实例化该类对应对象时才会被执行

      • 如果一个类没有类变量或者静态代码块，编译生成的字节码文件中不会有<clinit>()方法

      • 如果一个类有父类，JVM会保证子类<clinit>()执行前父类的<clinit>()方法已经执行

      • <clinit>方法中的代码不管是定义中的赋值语句还是静态代码块中的语句都是自上而下按顺序进行显式赋值，这些类变量在链接环节已经分配了内存，因此即使在源文件中静态代码块中的变量赋值语句在变量定义前面也能正常执行，只是静态代码块会先赋值，然后被变量定义处的赋值语句再次覆盖

      • 非法前向引用：在静态代码块后面定义的类变量只能在静态代码块中赋值，但是不能对在静态代码块中对该变量进行调用比如System.out.println(变量)，如果在静态代码块前面定义的变量则不存在该问题

      • 类的构造器对应的是<init>()方法[<init>方法在字节码文件的Methods下的<init>下的Code可以看到构造方法对应的字节码指令]

      • JDK8使用元空间即直接内存缓存已经加载完毕的Class对象，虚拟机类加载时始终只会执行一次<clinit>()方法保证类只被加载一次，虚拟机会给一个类的<clinit>()方法在多线程下加锁[类在第一次被实例化时初始化]，一个类在初始化的时候其他也在实例化该类的对象的线程都得等待<clinit>()方法执行完毕，如果我们在静态代码块中写的代码如果导致<clinit>()方法无法结束，会导致其他等待实例化该类对象的线程全部无限时阻塞等待且没有任何提示信息

   类加载初始化环节的执行条件[对类主动使用会执行初始化环节，被动使用不会执行初始化环节]

   1. 对类主动使用的七种情况[除了这七种情况其他都是被动使用]

      • 创建类实例

      • 访问某个类或者接口的类变量或者对该类变量赋值

      • 调用类的静态方法

      • 通过反射Class.forName("全限定类名")主动加载类对象

      • 初始化一个类的子类[加载一个类前会首先保证加载该类的所有父类]

      • JVM启动时被标明为启动类的类

      • JDK7开始提供的动态语言支持

    

2. 类加载器概念，类加载器举例

   • 类加载器简述：类加载器时JVM执行类加载机制的前提，类加载器负责通过各种方式将类的二进制数据流读入JVM内部并将其转换为一个与目标类对应的Class对象实例交给JVM进行链接和初始化操作，一个类是否可以运行不归类加载器管而由执行引擎决定，JVM支持引导型类加载器和自定义类加载器，JVM规范将所有直接或间接继承于抽象类ClassLoader的累加载器都划分为自定义类加载器，即JDK提供的扩展类加载器ExtClassLoader和系统类加载器AppClassLoader都间接继承自ClassLoader属于自定义类加载器

     • 类加载器在JDK1.0就出现了，那时只是单纯为了满足Java Applet即Java小程序研发出来的，如今类加载器在OSGI即热部署和热代码替换、字节码加解密领域大放异彩，类加载器在最初设计的时候就没有被绑定在JVM内部，不仅提供现成的类加载器实例，还允许用户自定义类加载并在系统中进行使用

     • 引导类加载器、扩展类加载器、系统类加载器、用户自定义类加载器在逻辑上依次构成了上下级关系，通过ClassLoader.getSystemClassLoader()可以获取Launcher$AppClassLoader，通过appClassLoader.getParent()可以获取extClassLoader，通过extClassLoader.getParent()尝试获取bootstrapClassLoader会返回null，因为设定上就不让用户获取到引导类加载器

       • Bootstrap Class Loader是用C++实现的，ExtClassLoader和AppClassLoader都是用Java实现的

     • 所有的类都是由类加载器加载的，用户自定义的类默认是通过单例appClassLoader来加载，Java的核心类库都是使用引导类加载器加载

     • 方法区的类信息会记录当前类是被哪个类加载器加载的，类加载器也会记录加载过哪些类，一旦类加载的加载过的类对象都被销毁了，相应的类加载器也会销毁

     • JVM将字节码文件加载到内存的加载方式分类[实际开发中一般都是两种方式混用]

       • 显示加载

         • 概念：在Java代码中通过显示调用类加载方法如Class.forName(name);、class.getClassLoader().loadClass(name);或者ClassLoader.getSystemClassLoader().loadClass(name);使用类加载器ClassLoader加载字节码文件

       • 隐式加载

         • 概念：不通过显示加载方式加载的字节码文件都是隐式加载，通过JVM自动控制加载过程，比如一个类引用了另一个类的对象，额外引用的类如果还没有被加载就会通过JVM自动加载到内存中

     • 系统需要支持类的动态加载或者需要对编译后的字节码文件进行加密解密操作时需要和类加载器打交道，开发者也可能需要自定义类加载器来重新定义类的加载规则来实现一些自定义的处理逻辑

       • 比如自定义类加载器就可以不遵循双亲委派模型来避免双亲委派机制的劣势

     • 类加载器的基本特征

       • 双亲委派模型是JDK1.2加入的类加载器机制，一开始类加载器并不遵守该机制。此外也不是所有的类加载器都遵守该模型，启动类加载器可能也会加载用户代码，JDK提供的标准API即使提供了默认的参考实现，但是仍然有可能需要用户来提供自己的实现，比如Java中的JNDI、JDBC、文件系统、Cipher等，都是利用JDK内部的ServiceProvider/ServiceLoader机制来实现的，这些情况不会使用双亲委派模型来加载而是使用上下文加载器加载

       • 可见性：子类加载器可以访问父类加载器加载的类，但是父类加载器不能访问子类加载器加载的类，基于这个可见性我们可以使用类加载器去实现容器的逻辑

       • 单一性：父类加载器的加载类的结果对子类加载器是可见的，只要父类加载器成功加载过一个类，子类就不会进行重复加载；但是像自定义类加载器这种可以创建多个类加载器实例，多个实例之间因为看不见对方的加载结果，同一个类仍然可能被同一种加载器类型的不同实例加载多次

   • 类的唯一性

     • 同一个虚拟机上使用同一个类加载器加载同一个字节码文件产生的类是唯一的，但是只要加载同一个字节码文件的类加载器不同，产生的类就不是相等的类，而保证一个字节码文件只会被同一个类加载器加载的机制是双亲委派机制。

     • 每个类加载器都有一个独立的类名称命名空间

       • 命名空间有该类加载器加载的类和其所有父类加载器加载的类组成

       • 同一个命名空间中不会出现全类名相同的两个类；不同命名空间中完全可能出现全类名相同的两个类，在大型应用中也会借助该特性来运行同一个类的不同版本，比如在Tomcat中让同一个工程通过不同类加载器的加载实现工程的隔离，在实际生产中应用比较广泛

     • 用户自定义的类加载器可以通过UserClassLoader loader = new UserClassLoader("D;\\code\workspace_idea5\\JVMDemo\\src\\");指定类加载器的要加载的字节码文件存放目录[不同的类加载器的加载目录是不一样的，系统类加载器的默认加载目录是out\\工程目录\\模块目录下]，并通过Class clazz = loader.findClass("com.earl.mall.Product");加载指定全类名的字节码文件生成对应的class实例

       • 用户自定义的类加载器如果没有设计为单例模式可以创建多个实例，那么每个实例都是一个全新的类加载器，此时使用不同的类加载器实例加载同一个字节码文件生成的class对象是不同的，此时同一个类就被加载了多次而且这些class对象都是不同的，这些class实例指向的方法区的Product类模板结构也是不同的，这些class实例通过getClassLoader()获取的类加载器都是UserClassLoader的不同实例，都不是同一个类加载器；在Tomcat中就能借助这个点实现应用的隔离

       • 如果运行程序时，程序中使用指定类加载器加载某个类，但是字节码文件又不在该类加载器的加载目录下会抛ClassNotFoundException异常

   • 类加载器分类

     • JVM规范将类加载器分为引导类加载器和自定义类加载器，即使是HotSpot自带的扩展类加载器和应用类加载器也和开发者自定义的类加载器一样被统称为自定义类加载器，凡是使用Java语言实现派生于抽象类ClassLoader的类加载器都被划分为自定义类加载器

     • 引导类加载器[启动类加载器]是扩展类加载器的逻辑父加载器，扩展类加载器是应用类加载器[系统类加载器]的逻辑父加载器，应用类加载器是所有用户自定义类加载器的逻辑父加载器，每种父类加载器都可以通过子类加载器的getParent()获取，只是引导类加载器无法被获取，调用该方法时会返回null，这个父只是指逻辑上的父子关系，和Java中的继承关系无关，只是一种包含关系指在子类加载器中包含着父加载器的字段引用

       • 实际设计是在ClassLoader中定义了parent字段，类加载器的构造器传参父类加载器并为字段赋值，后续继承ClassLoader都通过super(parent)调用ClassLoader中的单参构造方法

     • 引导类加载器

       • 引导类加载器使用C和C++实现嵌套在JVM的内部，负责加载Java的核心类库[JAVA_HOME/jre/lib/rt.jar|resources.jar或者sun.boot.class.path都是核心类库]，用于加载JVM自身需要的类，引导类加载器只加载包名为java、javax、sun打头的类

       • 引导类加载器加载扩展和应用类加载器，并将引导类加载器指定为二者的父类加载器

       • 引导类加载器没有继承自java.lang.ClassLoader，也没有父类加载器

       • 通过URL[] urls = sun.misc.Launcher.getbootstrapClassPath().getURLS();能获取引导类加载器负责加载的所有类的目录列表，通过url.toExternalForm()可以获取引导类加载器加载目录的绝对路径

       • 引导类加载器用户无法获取，任何获取引导类加载器的尝试最后都会获得null

     • 扩展类加载器

       • 扩展类加载器ExtClassLoader是Launcher类的内部类，间接继承自抽象父类ClassLoader，负责加载JAVA_HOME/jre/lib/ext子目录即扩展目录下的类库，如果用户创建的jar包放在该扩展目录下，jar包中的类也会自动由扩展类加载器加载，父类加载器为启动类加载器

       • 通过String extDirs = System.getProperty("java.ext.dirs");能够获取到扩展类加载器加载目录列表以分号分隔的拼接字符串，一般就两个目录JAVA_HOME/jre/lib/ext和C:\WINDOWS\Sun\Java\lib\ext

     • 应用/系统类加载器

       • 应用类加载器AppClassLoader是Launcher类[Lancher类是JVM的入口应用]的内部类，间接继承自抽象父类ClassLoader[AppClassLoader和ExtClassLoader一样直接继承自URLClassLoader]，负责加载环境变量classpath即用户自定义类或者系统属性java.class.path指定路径下的类库，是用户自定义类的默认类加载器，是用户自定义类加载器的默认父加载器，即使用户自定义类直接继承ClassLoader，其父类加载器还是系统类加载器；系统类加载器是使用频率最高的类加载器

       • 在Launcher类的构造器中先调用ExtClassLoader.getExtClassLoader()创建扩展类加载器，然后又调用AppClassLoader.getAppClassLoader()传参扩展类加载器将扩展类加载器作为AppClassLoader的父加载器创建系统类加载器，给具体的parent字段赋值是通过super(parent)调用顶级父类ClassLoader的构造器实现的，创建完系统类加载器以后会通过Thread.currentThread().setContextClassLoader(this.loader);将系统类加载器设置为默认的线程上下文类加载器

         • 扩展类加载器在调用构造器时传递的第二个参数parent值是null，用来表示引导类加载器

       • ClassLoader.getSystemClassLoader()获取的就是系统类加载器

     • 用户自定义类加载器

       • 自定义类加载器应用场景：

         • 隔离加载类[不同框架的类、框架和用户的类的全限定类名可能相同，大型主流框架一般都会自定义类加载器将框架和用户代码加载到不同环境中避免全限定类名相同的类发生冲突，类仲裁如果发现两个类的全类名相同会出现类冲突的问题，不解决会抛出异常]

           • tomcat这类Web应用服务器，内部也自定义了好几种类加载器，用于隔离同一个Web应用服务器上的不同应用程序

           • 利用类加载器的命名空间提供类似容器、模块化的功能实现类似进程内隔离的效果，比如，两个依赖于同一个类库的不同版本的模块，如果分别被不同的类加载器或者容器加载，就可以互不干扰，在类的隔离方面集大成者有JavaEE、OSGI和JPMS等

         • 修改类的加载方式[除了BootstrapLoader其他类加载器不是必须使用，用户可以根据自己需求自定义类加载器来替代扩展类加载器和应用类加载器]

         • 扩展加载源[除了上述字节码获取方式用户还想从数据库网络机顶盒等其他方式中获取字节码二进制信息流]

           • 任意能获取字节流的方式都能扩展系统从各种数据源获取字节码二进制数据流的能力，而不是只能从本地文件系统获取字节码信息

         • 防止源码泄露[java代码很容易被编译和篡改，可以通过自定义类加载器在加载过程中自动对字节码文件进行解密然后生成真正的字节码二进制信息流进行类加载防止源码泄漏]

       • 自定义类加载器的步骤

         • 继承ClassLoader，JDK1.2前继承ClassLoader需要重写loadClass()方法实现自定义类加载过程，JDK1.2以后不建议用户覆盖loadClass()方法，建议把自定义的类加载逻辑重写在findClass()方法中[将字节码文件以二进制流的形式写入并进行处理，如果是加密后的字节码文件需要先对字节流数据进行解密]

         • 如果自定义类加载器没有太复杂的需求可以直接继承URLClassLoader类，避免用户去自己重写findClass()，自定义类加载器一般都要直接或者间接继承自ClassLoader

         • Java开发者通过自定义类加载器实现类库从本地或者网络动态加载是Java语言繁荣的关键因素之一，比如OSGI组件框架和Eclipse的插件机制都是通过类加载器实现的插件机制，能够实现为应用程序提供动态增加新功能，实现热部署无需重新打包发布应用程序

         • 自定义类加载器还可以实现应用的隔离，像tomcat、spring等中间件组件框架都在内部实现自定义类加载器隔离不同的组件模块，这方面要比C/C++好太多了，要想不修改C/C++程序就能为应用添加新功能几乎是不可能实现的

       • 自定义类加载器的实现方式

         • 1️⃣自定义类加载器继承自ClassLoader重写loadClass()方法指定类加载的完整逻辑，通过重写该方法可以避免自定义类加载器使用双亲委派机制

         • 2️⃣自定义类加载器继承自ClassLoader重写findClass()方法指定字节码文件的加载以及转换成二进制流的逻辑，该方法被loadClass()方法调用，可以保证自定义类加载器仍然遵守双亲委派机制

         • 自定义类加载器可以通过重写loadClass()方法抹去双亲委派机制，此时是否能用自定义的类加载器加载核心API呢？还是不行，因为JDK还为核心类库提供了一层保护机制，不管是自定义类加载器还是JDK提供的类加载器，最后都要调用JDK提供的本地方法defineClass()，该方法会调用preDefineClass()提供对JDK核心类库的保护

         • 自定义类加载器的父类加载器都是系统类加载器

       • 代码实现

         • 注意事项

           • ClassLoader中的loadClass方法调用findClass方法，loadClass中主要实现了双亲委派机制，findClass中定义了字节码二进制信息流的查找加载方式，并调用defineClass本地方法传参字节码二进制流获取class对象

           • 所有的自定义类加载器都应该继承ClassLoader，开发者可以根据需要选择重写loadClass方法或者defineClass方法，JVM建议重写findClass不要重写loadClass避免破坏双亲委派模型破坏原有结构造成系统容易出现问题，开发者定义好自定义类加载器后只需要调用对应的loadClass方法就行，既能保证双亲委派模型，也能保证自定义字节码二进制信息流的自定义加载方式

           • 所有类的加载包括JDK核心类库的加载都使用的ClassLoader的loadClass方法

         • 实现步骤

           • 创建一个自定义类加载器继承自ClassLoader

           • 声明一个字段指定类加载器的类加载目录

           • 重写findClass(String name)方法定义根据传入的全类名找到字节码文件并加载字节码二进制信息流到JVM中，调用本地方法defineClass传入字节码二进制数组获取class对象并返回

         [示例代码]

         xxxxxxxxxx
         package io.renren.classloader;
         
         import java.io.BufferedInputStream;
         import java.io.ByteArrayOutputStream;
         import java.io.FileInputStream;
         import java.io.IOException;
         
         public class CusClassLoader extends ClassLoader {
             private String loadPath;
         
             public CusClassLoader(String loadPath) {
                 this.loadPath = loadPath;
             }
         
             public CusClassLoader(ClassLoader parent, String loadPath) {
                 super(parent);
                 this.loadPath = loadPath;
             }
         
             public static void main(String[] args) {
                 CusClassLoader loader = new CusClassLoader("d:/");
                 try {
                     Class<?> clazz = loader.loadClass("com.earl.mall.Product");
                     System.out.println("加载此类的类加载器为: " + clazz.getClassLoader().getClass().getName());//加载此类的类加载器为: io.renren.classloader.CusClassLoader
                 } catch (ClassNotFoundException e) {
                     e.printStackTrace();
                 }
             }
         
             @Override
             protected Class<?> findClass(String name) throws ClassNotFoundException {
                 BufferedInputStream bis = null;
                 ByteArrayOutputStream baos = null;
                 name = name.replaceAll("\\.", "/");
                 try {
                     String byteCodeFilePath = loadPath.concat(name).concat(".class");
                     bis = new BufferedInputStream(new FileInputStream(byteCodeFilePath));
                     //准备字节数组输出流ByteArrayOutputStream将输入流中的数据通过输出流写出到内存中输出流实例中的byte数组中
                     baos = new ByteArrayOutputStream();
                     int len;
                     byte[] buffer = new byte[1024];
                     while ((len = bis.read(buffer)) != -1) {
                         //将字节码字节数组写到ByteArrayOutputStream实例中的数据数组中
                         baos.write(buffer, 0, len);
                     }
                     //将字节码文件字节数据封装成byte数组
                     byte[] byteCode = baos.toByteArray();
                     return defineClass(null, byteCode, 0, byteCode.length);
                 } catch (IOException e) {
                     e.printStackTrace();
                 } finally {
                     try {
                         if (baos != null)
                             baos.close();
                     } catch (IOException e) {
                         e.printStackTrace();
                     }
                     try {
                         if (bis != null)
                             bis.close();
                     } catch (IOException e) {
                         e.printStackTrace();
                     }
                 }
                 return null;
             }
         }
         

       • 注意涉及到两个类型做类型转换时，只有两个类型都被同一个类加载器加载才能进行类型转换，否则类型转换时会发生异常

       • JDK9以后系统类加载器变成了ClassLoaders的内部类了，系统类加载器的父类加载器变成了ClassLoaders$PlatformClassLoader而不再是扩展类加载器了，平台类加载器的父类加载器是引导类加载器，因为JDK9新特性模块化系统导致类加载器也有了一些新变化

         • 扩展机制被移除，扩展类加载器被重新命名为平台类加载器，可以通过ClassLoader.getPlatformClassLoader()来获取

         • JDK9是基于模块化构建的，将原来的tr.jar、tools.jar拆分成数十个JMOD文件，Java类库天然满足了可扩展的需求，无需再保留JAVA_HOME\lib\ext目录，此前使用JAVA_HOME\lib\ext目录或者java.ext.dirs系统变量来扩展JDK的功能已经没有继续存在的价值了

         • 平台了加载器和系统类加载器都不再继承自java.net.URLClassLoader，启动类加载器BootClassLoader、平台类加载器、系统类加载器全部继承自jdk.internal.loader.BuiltinClassLoader，BuiltinClassLoader继承自SecureClassLoader，JDK9以后得版本自定义类加载器就不能继承自URLClassLoader了；引导类加载器也变成了JVM和Java类库共同协作实现的类加载器，但是为了向下兼容，尝试获取启动类加载器仍然会返回null

         • 类加载器有了名称，新增了getName()方法来获取类加载器的名称，该方法主要用于与类加载器的调试相关场景下

         • 双亲委派机制也发生了一些变化，Java代码被划分成了若干模块，不同的模块由不同的类加载器进行加载，因此在进行类加载在把当前类委派给父类加载器加载前先判断当前类是否能归属到某一个系统模块中，如果是就找哪一个类加载器负责加载该模块并直接将当前类交给对应类加载器进行加载

   • 获取类加载器的几种方式

     • 通过类对象class.getClassLoader()获取指定类对象类加载的类加载器

       • 数组比如String[]的类型是[Llang.java.String;，在JVM中没有数组这种类型，实际上还是JVM加载String这种类型然后动态地创建几个内存连续的相同类型元素，但是数组对象arr仍然能调用arr.getClass().getClassLoader();，只是此时的结果是null，数组类的类加载器和数组中元素类型的类加载器是一样的，比如String类型元素数组的类加载器是引导类加载器，如果数据的元素类型是基本数据类型[基本数据类型是虚拟机预设的不需要类加载器加载]，数组类是没有类加载器的[这种情况下也是返回null]

     • 通过当前线程上下文Thread.currentThread().getContextClassLoader()获取当前代码所在类的负责加载的类加载器，默认情况下上下文类加载器就是系统类加载器

     • 通过ClassLoader.getSystemClassLoader().getParent()可以依次获取到应用类加载器和扩展类加载器

   • 类加载器的继承结构

     • ClassLoader是一个没有抽象方法的抽象类，其中定义了loadClass(String)、resolveClass(Class<?>)、findClass(String)、defineClass(byte[],int,int)比较重要的几个方法，设置成抽象类只是让其不能实例化，但是其中有方法体为空的方法比如findClass(String)

       • 功能是通过类的全类名去加载字节码二进制流

       • public final ClassLoader getParent()：获取当前类加载器的父类加载器

       • public Class<?> loadClass(String name) throws ClassNotFoundException：基于双亲委派机制加载全类名为name的字节码文件或者网络传输的二进制流数据，返回对应类的Class实例，如果找不到指定类则抛ClassNotFoundException，该方法的实现就是双亲委派机制的实现

         • 该方法就是ClassLoader.getSystemLoader().loadClass("com.earl.mall.Product")时的逻辑

         xxxxxxxxxx
         classLoader.loadClass(name)
         public Class<?> loadClass(String name) throws ClassNotFoundException {
             return loadClass(name, false);1️⃣ 
         }
         
         1️⃣classLoader.loadClass(name, false)
         protected Class<?> loadClass(String name, boolean resolve)
                 throws ClassNotFoundException
         {//入参resolve为true表示加载类的同时进行解析环节，该参数为false表示不需要解析
             synchronized (getClassLoadingLock(name)) {//为加载类操作上锁，保证类只会被加载一次
                 Class<?> c = findLoadedClass(name);//首先去缓存即类加载器的命名空间中检查是否已经加载过同名类，如果已经存在直接返回对应`class`对象无需加载，否则返回null
                 if (c == null) {//没有被加载过进入if语句块进行加载
                     long t0 = System.nanoTime();//获取系统时间
                     try {
                         //如果当前类加载器不是引导类加载器就递归调用父类加载器的loadClass(name, false)方法让父类加载器来进行类加载,这里的递归会先找到引导类加载器，引导类加载器加载不了才会在后续返回每次递归调用的后序遍历时依次从上
                         if (parent != null) {
                             c = parent.loadClass(name, false);
                         } else {
                             //如果扩展类加载器的父类加载器是引导类加载器就检查引导类加载器是否能够加载当前类
                             c = findBootstrapClassOrNull(name);//如果引导类加载器不能加载会返回null
                         }
                     } catch (ClassNotFoundException e) {
         
                     }
         
                     if (c == null) {
                         //如果当前类加载器的父类加载器不能加载当前类调用findClass(name)判断当前类加载器是否能加载当前类，如果还是不能加载就返回上一次子类加载器调用c = parent.loadClass(name, false);处返回null表示当前父类无法加载当前类，子类加载器在重复这个过程判断自身是否能加载当前类，说白了就是递归的后序遍历判断当前类加载器是否能加载当前类，这就是双亲委派机制的实现方式
                         long t1 = System.nanoTime();
                         c = findClass(name);
         
                         // thi is the defining class loader; record the stats
                         sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                         sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                         sun.misc.PerfCounter.getFindClasses().increment();
                     }
                 }
                 if (resolve) {
                     resolveClass(c);
                 }
                 return c;
             }
         }
         

       • protected Class<?> findClass(String name) throws ClassNotFoundException：ClassLoader的findClass(name)方法没有方法体，如果不重写就进行调用会抛出ClassNotFoundException(name)异常，该方法在子类URLClassLoader中做了重写，在扩展类加载器和系统类加载器中都没有重写该方法，即扩展类加载器和系统类加载器都使用URLClassLoader重写的findClass(name)逻辑；只能在同一个包、子包或者子类中调用

         • 功能：该方法会在检查完父类加载器是否能加载当前类后被loadClass()方法调用检查当前类加载器能否加载当前类，实际上loadClass()主要实现双亲委派机制，findClass()才是判断当前类是否能被当前类加载器加载并进行加载的方法

         • 在JDK1.2以前还没有双亲委派机制自定义类加载器总是会重写loadClass方法实现自定义的类加载逻辑，JDK1.2以后已经不再建议开发者去覆盖loadClass()方法而是将类加载的逻辑写在findClass()方法中来保证自定义的类加载器也符合双亲委派机制

         • findClass()方法通常和defineClass()方法一起使用，自定义类加载器通过重写findClass()方法自定义类加载规则，取得加载器的字节码二进制流后调用defineClass()方法生成对应的类的class实例；一般自定义类加载器都是重写findClass()方法来编写字节码二进制流的加载规则，然后通过调用defineClass()方法解析二进制码生成class对象

         [uRLClassLoader.findClass(name)]

         xxxxxxxxxx
         protected Class<?> findClass(final String name) throws ClassNotFoundException
         {
             final Class<?> result;
             try {
                 result = AccessController.doPrivileged(
                     new PrivilegedExceptionAction<Class<?>>() {
                         public Class<?> run() throws ClassNotFoundException {
                             String path = name.replace('.', '/').concat(".class");//拼出字节码文件的相对路径
                             Resource res = ucp.getResource(path, false);//通过字节码文件的相对路径获取字节码数据
                             if (res != null) {
                                 try {
                                     return defineClass(name, res);//通过字节码二进制数据创建class实例并直接返回
                                 } catch (IOException e) {
                                     throw new ClassNotFoundException(name, e);
                                 }
                             } else {
                                 return null;
                             }
                         }
                     }, acc);
             } catch (java.security.PrivilegedActionException pae) {
                 throw (ClassNotFoundException) pae.getException();
             }
             if (result == null) {
                 throw new ClassNotFoundException(name);
             }
             return result;
         }
         

         [uRLClassLoader.defineClass(name, res)]

         xxxxxxxxxx
         private Class<?> defineClass(String name, Resource res) throws IOException {
             long t0 = System.nanoTime();
             int i = name.lastIndexOf('.');
             URL url = res.getCodeSourceURL();
             if (i != -1) {
                 String pkgname = name.substring(0, i);
                 // Check if package already loaded.
                 Manifest man = res.getManifest();
                 definePackageInternal(pkgname, man, url);
             }
             // Now read the class bytes and define the class
             java.nio.ByteBuffer bb = res.getByteBuffer();
             if (bb != null) {
                 // Use (direct) ByteBuffer:
                 CodeSigner[] signers = res.getCodeSigners();
                 CodeSource cs = new CodeSource(url, signers);
                 sun.misc.PerfCounter.getReadClassBytesTime().addElapsedTimeFrom(t0);
                 return defineClass(name, bb, cs);
             } else {
                 byte[] b = res.getBytes();
                 // must read certificates AFTER reading bytes.
                 CodeSigner[] signers = res.getCodeSigners();
                 CodeSource cs = new CodeSource(url, signers);
                 sun.misc.PerfCounter.getReadClassBytesTime().addElapsedTimeFrom(t0);
                 return defineClass(name, b, 0, b.length, cs);
             }
         }
         

       • protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError

         • 功能：传入一个字节码二进制流解析得到JVM能识别的Class对象，off是从第几个字节开始读，len是读取字节的长度，通过该方法可以把字节码文件实例化为class对象，我们也可以从网络中获取字节码二进制流使用该方法创建class对象

         xxxxxxxxxx
         protected final Class<?> defineClass(String name, byte[] b, int off, int len)
             throws ClassFormatError
         {
             return defineClass(name, b, off, len, null);
         }
         
         protected final Class<?> defineClass(String name, byte[] b, int off, int len,
                                              ProtectionDomain protectionDomain)
             throws ClassFormatError
         {
             protectionDomain = preDefineClass(name, protectionDomain);
             String source = defineClassSourceLocation(protectionDomain);
             Class<?> c = defineClass1(name, b, off, len, protectionDomain, source);
             postDefineClass(c, protectionDomain);
             return c;
         }
         
         private native Class<?> defineClass1(String name, byte[] b, int off, int len,
                                              ProtectionDomain pd, String source);
         

       • protected final void resolveClass(Class<?> clazz)

         • 该方法可以手动在Class对象创建完成时执行解析操作

       • protected final Class<?> findLoadedClass(String name)

         • 查找并返回名称为name已经被加载过的class实例，如果没找到返回null

     • SecureClassLoader继承自ClassLoader，URLClassLoader继承自SecureClasssLoader

       • URLClassLoader重写了ClassLoader中的findClass(name)、findResource()等方法，在扩展类加载器和系统类加载器中都没有重写该方法，即扩展类加载器和系统类加载器都使用URLClassLoader重写的findClass(name)逻辑，此外还增加了URLClassPath类协助获取字节码流等功能，开发者在自定义类加载器时如果没有太复杂的业务需要，可以直接继承自URLClassLoader避免自己去编写findClass()方法以及其他获取字节码流的方法，更便捷地自定义类加载器

       • SecureClassLoader中增加了对代码源的位置和证书的验证以及对字节码的访问权限验证的方法，开发者一般只会和他的子类URLClassLoader打交道

     • 扩展类加载器和系统类加载器都继承自URIClassLoader

       • 在系统类加载器中对ClassLoader的loadClass(String,boolean)方法进行了重写，这里面只是增加了一些判断的操作，判断之后最终仍然通过super.loadClass()调用ClassLoader实现的loadClass()方法

       • 这两个类加载器因为都调用的是ClassLoader实现的loadClass()方法，因此都遵循双亲委派机制

   • Class.forName()和ClassLoader.loadClass的区别

     • Class.forName()是一个静态方法，传参类的全限定类名返回一个Class对象，加载类的同时会进行类的初始化阶段

     • ClassLoader.loadClass()是一个实例方法，需要一个类加载器实例来调用，该方法只会加载一个类，但是不会执行类的初始化阶段并调用<clinit>()方法，只有该类在第一次主动使用时才会进行初始化，而且也不会执行类的解析环节，但是可以指定类的加载器

3. 简述类的生命周期

   • 基本数据类型由虚拟机预先定义[不需要进行类加载]，引用数据类型需要类[类是统称，除了类还可以指代接口、注解、枚举类]的加载

     • 使用类的时候会先判断当前类是否已经被类加载过，如果还没有加载过就需要使用对应的类加载器进行加载，加载过程中会对字节码文件做验证操作，如果不是合法的字节码文件会抛出相关的异常；验证没问题就可以继续进行链接阶段的准备、解析对类变量进行默认赋值并将符号引用改成直接引用，然后在初始化阶段对类变量进行显示赋值；初始化完成类就被成功加载了，此时就会在方法区存放被加载类的模板，调用类的静态方法、创建类的实例或者调用类的成员变量都属于对类的使用环节，类使用完毕以后会对类进行卸载

       • 有些类的生命周期和JVM一样是无法被卸载的，类被回收需要方法区进行GC，没有进行GC即使类使用结束也不会立即被回收，

   • 类的生命周期中的七个阶段

     • 加载

       • 职责：将字节码文件加载到机器内存中，并在内存中构建Java类的原型--类模板对象，类模板对象就是Java类在JVM内存中的一个快照，保存着从字节码文件中解析出来的常量池、类字段、类方法等信息；JVM在运行期能通过类模板获取Java类中的任意信息，访问成员变量以及调用方法

         • 反射机制就是基于JVM内存中的类模板

         • 类加载器只和加载阶段有关，加载阶段结束，方法区的类模板结构和堆中的Class实例都会完成创建，类加载器和链接环节以及初始化环节没有关系，这两个环节由JVM负责

       • 具体任务

         • 在src目录开始根据类的全名获取类的二进制数据流

           • 通过Class clazz = Class.forName("java.lang.String");可以手动加载类并获取对应的Class实例

         • 解析二进制数据类为方法区的Java类模板

         • 在堆中创建当前类的java.lang.Class实例作为方法区该类模板的各种数据的访问入口

           • Class实例是instanceKlass实例的一个镜像，是访问类型元数据的入口，也是实现反射的入口，通过class实例能访问类模板中的各种数据，可以把class对象狭隘地理解为指向类模板结构

           • Class类的构造器是私有的，只有JVM能够创建

           • 通过Class对象可以通过反射获取当前类声明的所有方法、获取每个方法的修饰符、返回值类型、方法名、参数列表

       • 获取二进制流的方式

         • 磁盘上的字节码文件

         • 读入jar、zip等归档数据包提取类文件

         • 存在数据库中类的二进制数据

         • 使用网络协议通过网络进行传输加载

         • 运行时动态生成类的二进制信息

         • 🔎：如果输入的数据不是字节码文件的格式会抛出ClassFormatError异常

       • 数组类的加载

         • 数组类本身不是由类加载器负责加载创建的，JVM运行时根据元素类型和数组维度可以直接创建，数组的元素类型如果是引用数据类型此时才会使用到类加载器加载对应元素的类

     • 链接

       • 验证

         • 职责：保证加载的字节码是符合JVM规范的，验证包含格式检查、语义检查、字节码验证、符号引用验证四个环节

         • 格式检查：包含魔数检查、版本检查、指令长度检查，格式检查会和加载阶段同时执行，格式检查成功后才会将类的二进制数据信息加载到方法区中；在方法区生成类模板以后才会进行后续三个验证环节

         • 语义检查：检查字节码信息在语义上是否符合JVM规范，例如除Object外所有的类的属性表中都有指定父类、检查被final修饰的方法或者类没有被重写或者继承过、非抽象类是否实现了所有抽象方法或者接口方法、检查是否存在不兼容的方法[方法不同同名的情况下形参列表还相同、方法不能同时被abstract和final修饰]

         • 字节码验证：对字节码流进行分析，判断字节码是否可以被正确执行；比如检查字节码执行过程中是否会跳转到一条不存在的指令、方法的调用和变量的赋值已经指令的调用是否传递了正确类型的参数

           • 栈映射帧[StackMapTable]：用于检测在特定字节码处。局部变量表和操作数栈是否有正确的数据类型，该过程只能尽可能检查可以明显预知的问题，不能完全确定字节码可以被安全执行，没有通过该检查的类不会被虚拟机装载，通过了也不能证明这个类没有问题；StackMapTable在方法表的Code属性中的属性表的StackMapTable中

         • 符号引用验证：符号引用验证在解析环节才会执行，用于校验符号引用对应的类或者方法是否确实存在，并且当前类有访问这些数据的权限，如果要使用的类在系统中找不到会抛出NoClassDefFoundError，如果一个方法在系统中找不到会抛出NoSuchMethodError

       • 准备

         • 职责：为静态变量分配内存并初始化为默认值，为字面量声明的常量进行显示赋值

           • 相当于为类变量分配内存并赋值默认值时常量直接赋值最终值，因为常量不能被重复赋值不能像静态变量一样在解析环节再进行显示赋值

           • 常量如果是对象实例比如static final String str = new String("123")在初始化阶段执行<clinit>()方法时才会被显示赋值，对应字节码中字段表中的字段也不会有属性ConstantValue，但是通过字面值声明的常量字段表中的对应字段有ConstantValue属性

           • 准备阶段不会执行任何初始化代码

           • 老师的结论有点啰嗦：使用static+final修饰且显示赋值中不涉及到方法或者构造器调用的基本数据类型或String类型的显示赋值在链接阶段的准备环节进行

       • 解析

         • 职责：将类、接口、字段和方法的符号引用转换为直接引用

         • 类模板中有方法表，所有的方法都列在表中，需要调用一个类的方法时只要知道该方法在方法表中的偏移量就可以直接调用该方法，通过解析环节可以将符号引用转换为在对应类方法表中的位置，从而使得方法具备被实际调用的条件；要得到一个类、方法、字段在内存中的指针或者偏移量，对应类一定被加载完成；

         • 在HotSpot中加载、验证、准备和初始化都会按顺序执行，但是解析一般会在初始化完成后再执行

         • Java中直接使用字符串常量是会在类的常量池中出现一个CONSTANT_String结构表示一个字符串常量，该常量会引用一个字符串字面量CONSTANT_utf8_info，JVM运行时常量池中会维护一个字符串拘留表[就是串池，JDK7开始移入了堆空间]，会保留所有出现过的字符串常量并且保证没有重复项，以CONSTANT_String结构出现过的字符串都会在串池中创建对应的字符串对象

     • 初始化

       • 职责：初始化类的静态变量为静态变量进行显式赋值，在初始化阶段才会真正开始执行类中定义的Java程序代码[静态代码块、静态变量的显示赋值语句]，初始化以前的步骤没问题说明类可以被顺利装载到系统中，初始化阶段最重要的工作是执行类的初始化<clinit>()方法，该方法由前端编译器生成并由JVM调用，是由常量的代码显示赋值语句、静态变量的赋值语句以及静态代码块合并产生

       • 在加载一个类前虚拟机总会先加载其父类，因此父类的<clinit>()总是先于子类的<clinit>()之前被调用，对应的父类的静态方法总是先于子类的静态方法先执行

       • <clinit>()方法会合并有显示赋值语句的静态变量、采用代码而非字面量显示赋值的常量、静态代码块的代码，对于非静态字段、没有显示赋值的静态字段以及没有显示赋值以及使用字面量赋值的常量都不会参与生成<clinit>()方法

         • 静态代码块是类的初始化代码块，接口中不能有静态代码块

       • <clinit>()的线性安全性问题

         • JVM会确保<clinit>()方法调用时的线程安全性，保证<clinit>()方法只被执行一次，<clinit>()方法的访问标志只有一个static，没有带synchronized，<clinit>()的锁是一个隐式的锁，如果<clinit>()方法没有明确的终止时间，可能导致多个线程阻塞导致死锁，这种死锁是很难发现的，因为我们看不到相应的锁信息，而且这种死锁无法通过jvisualvm看到

         • 一个典型的场景是在A的静态代码块中去加载B，且在B的静态代码块中去加载A，如果两个类同时被两个线程加载会因为都在等对方加载完导致两个类的加载发生死锁，最终导致所有需要加载这两个类的线程全部阻塞等待，因此在一个类的静态代码块中加载另外一个类一定要特别小心

       • Java程序对类的使用分为主动使用和被动使用两种

         • 一个类被主动使用<clinit>()方法才会被调用，被动使用不会调用<clinit>()方法，即一个类被成功加载不一定会执行初始化阶段

         • JVM规定类或者接口只会在首次使用时才会被装载，而且只有在主动使用的情况下加载类才会进行初始化阶段，被动使用的类通常会进行类加载但是不会经历初始化阶段

         • 主动使用的情况

           • 1️⃣使用new关键字、或者通过反射、克隆、反序列化创建一个类的实例

           • 2️⃣使用字节码指令invokestatic调用类的静态方法

           • 3️⃣使用字节码指令getstatic、putstatic访问或者赋值类或者接口的静态字段或者非字面量显示赋值的常量，注意使用字面量显示赋值的常量被访问不会触发类加载的初始化阶段

           • 4️⃣使用java.lang.reflect包中的反射类的方法时，比如Class.forName(str)

           • 5️⃣初始化子类时发现父类还没有初始化触发父类的初始化

             • 这个规则不适用于接口，初始化一个类时并不会先初始化他实现的接口，初始化一个接口时也不会先初始化他的父接口；接口只有在程序首次使用接口中的静态字段或者访问非字面量显示赋值的常量时才会进行初始化

           • 6️⃣一个接口定义了被default关键字修饰的默认方法，直接或者间接实现该接口的类初始化，在该类初始化以前会触发该接口初始化

           • 7️⃣JVM启动时会通过引导类加载器初始化main()方法所在的类，主方法的执行将依次导致所需的类的加载、链接和初始化

           • 8️⃣首次调用MethodHandle实例时需要初始化该MethodHandle指向的方法所在的类[即涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类需要先进行初始化]

             • MethodHandle：这是反射包下的一个类

         • 被动使用的情况

           • 访问一个静态字段时只有真正声明该字段的类才会被初始化，比如通过子类引用访问父类中声明的静态变量不会导致子类初始化，但是子类仍然会被加载

           • 定义引用类型数组不会触发该类的初始化

             • 比如Parent[] parents = new Parent[10]，parents的类型为[Lcom.earl.java.Parent数组类型，数组类型的父类也是Object，只是通过上述语句创建parents数组不会涉及Parent类的初始化，在调用Parents[0]=new Parent();的时候才会触发Parent类的初始化

           • 使用在链接阶段的准备环节已经被字面值显示赋值的常量不会触发常量声明所在类或者接口的初始化

             • int CONSTANT=new Random().nextInt(10);实际上是一个非字面量显式赋值的常量[因为接口中的变量默认修饰符是public static final]，在接口类加载时的初始化阶段通过<clinit>()方法进行赋值

           • 调用ClassLoader类的loadClass()方法比如Class clazz = ClassLoader.getSystemClassLoader().loadClass("com.earl.mall.Product");加载一个类不会触发初始化阶段

             • 注意Class.forName("com.earl.mall.Product")加载一个类会触发初始化阶段

     • 使用

       • 职责：开发人员可以在程序中访问和调用类的静态字段和静态方法，或者使用new关键字创建指定类的对象实例，创建对象实例以后可以通过对象去访问非静态字段和实例方法

     • 卸载

       • 职责：

       • 一个Class对象总会引用它的类加载器，通过class.getClassLoader()方法可以获取到对应的类加载器，类加载器中也会维护一个集合来存放当前类加载器加载的类的Class对象，这种关系称为双向关联关系

       • 对象实例可以通过getClass()方法获取对应类的class对象，即class对象会被类对应的所有实例引用

       • 当一个Class对象没有被任何对象实例引用时，Class对象就会结束生命周期被回收，方法区的类模板数据也会被卸载从而结束类的生命周期，Class对象被销毁，方法区中的类模板结构因为没有被引用才会回收

       • 类的回收比较麻烦，判断一个类不再使用的条件很苛刻，需要同时满足以下三个条件才允许当前类被回收，但是也不是像对象一样没有引用了就必然被回收，一个已经被加载的类被卸载的概率很小且就算卸载卸载的时间也不能确定，因此开发者开发系统功能时不应该把特定类型的卸载作为功能的假设前提

         • 该类的所有实例都已经被回收即堆中不存在该类及任何派生子类的实例，只要有一个实例存在，实例就会有一个指针指向Class对象，Class对象指向当前类在方法区的类型信息

         • 加载该类的加载器已经被回收，Class对象记录了当前类是被哪个类加载器加载的，类加载器中的集合也记录了加载过具体哪些类，这个条件除非是精心设计的可替换类加载器场景比如OSGI和JSP的重加载，否则一般是很难达成的，注意类加载器加载的所有类都卸载的情况下类加载器也会销毁

           • 启动类加载器加载的类即Java的核心API在整个JVM运行期间都不会被卸载，启动类加载器本身也不可能被卸载，JVM规范和JLS规范[Java语言规范]都提到了这点

           • 系统类加载器和扩展类加载器实例在JVM运行期间也不会被卸载，总是能被直接或者间接地访问到，因此被系统类加载器和扩展类加载器加载的类型也不太可能在JVM运行期间被卸载

           • 开发者自定义的类加载器实例一般会采用缓存策略缓存起来提高系统性能，因此被用户自定义加载器加载的类型在JVM运行期间也几乎不太可能被卸载，这些类型只有在很简单的上下文环境中还要借助强制调用垃圾回收功能才能被卸载，因为垃圾回收的时间不确定因此即便这些类被卸载，卸载的时间也是无法确定的

         • 当前类的class对象没有在任何地方被引用过，即没有在任何地方使用反射来访问该类，class对象可能被直接引用，或者被当前类的实例引用或者被类加载器引用

       • Class对象的引用全部断开后，如果再次需要使用对应类，会首先检查CLass对象是否还存在，如果存在则直接使用Class对象当前类不需要重新加载，如果Class对象已经不存在，JVM会重新加载当前类

     • 🔎：其中验证、准备、解析三个环节统称为链接阶段，因此也可以说类的生命周期有五个阶段，加载-链接(验证-准备-解析)-初始化-使用-卸载

4. 类文件结构

   • JVM中两个class对象是同一个类要求class对象的全限定类名完全一致且两个class对象的类加载器对象必须相同，

   • 即使来自同个Class文件，只要类加载器实例不同，两个class对象就不相等；class对象的类加载器引用会作为类的信息保存在方法区中

5. 类加载器可以打破双亲委派吗，怎么打破

   • 双亲委派机制

     • 双亲委派机制原理

       • 1️⃣：如果一个类加载器收到类加载请求，该类加载器会首先委托其父类加载器去执行该类加载请求

       • 2️⃣：如果父类加载器还存在父类加载器，则继续委托其父类加载器执行该类加载请求；最终会委托给引导类加载器

       • 3️⃣：此时如果当前类加载器可以完成类加载任务就由当前类加载并直接返回，如果当前类无法完成该加载任务就由当前类加载器的子类加载器去尝试完成类加载任务并返回

       • 例子：小孩拿着苹果问"妈妈你吃吗?"，妈妈拿着苹果问奶奶"妈妈你吃吗?"，奶奶说我吃就奶奶吃，奶奶说我不吃妈妈说我吃就妈妈吃，妈妈说我不吃就小孩吃

       • 双亲委派模型是在类加载器的公共父类ClassLoad中的loadClass()方法中通过递归判断当前类是否被加载器过并找父类加载器直到引导类加载器，然后依次在返回递归调用前即递归的后序遍历挨个判断是否能被当前类加载器加载，能加载直接加载返回，如果不能加载就返回null，子类加载器再判断是否能加载，如果所有类加载器遍历了都无法加载则抛出ClassNotFoundException

     • 双亲委派机制的代码实现逻辑

       • 🔎：双亲委派机制在java.lang.ClassLoader的loadClass(String,boolean)方法中实现的，具体的实现逻辑如下

         • 注意即使是核心API的类也是从系统类加载器依次向上找父类直到找到引导类加载器

       • 在当前类加载器的命名空间中查找有无当前类的class对象，如果有直接返回

       • 判断当前类加载器的父类加载器是否为null，不为null说明父类加载器不是引导类加载器，调用父类的loadClass(String,boolean)方法尝试让父类去加载当前类

       • 如果当前类加载器的父类加载器为null即是引导类加载器，则调用findBootstrapClassOrNull(name)尝试让引导类加载器判断是否加载过并尝试进行加载

       • 如果父类加载器无法成功加载当前类，则当前类加载器调用findClass(name)判断当前类加载器是否能进行加载，如果能加载会调用ClassLoader中的本地方法defineClass()方法加载目标Java类

     • 为了保护系统不因为引入全限定类名相同的类就导致项目使用的类被篡改导致系统崩溃，引入双亲委派机制；

       • 自定义类与核心包存在类全限定类名相同虽然是错误写法但是不会报错

       • 比如如果系统注入了一个与Java核心包全限定类名相同的类，此时由于双亲委派机制会由引导类加载器去加载核心包路径下JDK提供的那个类而不会去加载全限定类名相同的用户自定义类，核心包中的类全都没有main方法，如果用户自定义类的全限定类名和核心包的类相同还有main方法，会直接报错该类中没有main方法，因为只会去加载核心包的同名类

       • 注意如果自定义的类的全限定类名在核心包没有，但是包名和核心包一样也会报错，因为Java不允许用户自定义类使用核心包名，这是为了避免用户通过让自定义类和核心包的包名相同使用引导类加载器来加载自定义类，避免用户对引导类加载器进行攻击

     • 注意核心包下一些类只有接口，自实现由第三方提供，这些实现类使用当前线程上下文Thread.currentThread().getContextClassLoader()获取类加载器执行类加载，默认是应用类加载器

   • 双亲委派机制优势和弊端

     • 优势

       • 类加载器有层次关系导致类也有层次关系，双亲委派机制可以，确保一个类只能被唯一确定的类加载器加载，而且加载前还会去检查类加载器的命名空间中是否因为类已经被加载过有对应的class对象，确保类的全局唯一性避免类被重复加载

       • 保护系统安全，率先使用引导类加载器加载核心包防止用户通过命令相同全类名的类来篡改核心API，不允许使用核心包包名防止引导类加载器被用户随意使用[使用核心API的包名会导致JVM启动报错并抛出SecurityException]，这种对java核心源代码的保护被称为沙箱安全机制

     • 弊端

       • 双亲委派模型会导致顶层的类加载器无法访问底层类加载器所加载的类，这会导致系统核心类无法访问用户自定义的应用类，比如JDK在系统类中提供一个接口，该接口在应用类中得到实现，该接口还绑定了一个工厂方法用于创建接口的实例，但是因为接口和工厂方法都在启动类加载器中，此时会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题

         • JVM只是建议采用双亲委派模型，并没有明确要求，Tomcat的类加载器使用的加载机制和传统双亲委派模型有一定区别，当缺省的类加载器接收到一个类加载器任务首先会自行进行加载，加载失败了才会将类的加载任务委派给其父类加载器去执行，这也是Servlet规范推荐的做法

   • 双亲委派机制的破坏方式

     • 🔎：实际开发中有很多场景都需要上层类加载器加载的类需要使用到下层类加载器加载的类的实现，需要避开双亲委派模型单向委托的行为，有三种典型破坏双亲委派机制的行为

     • 1️⃣JDK1.2以前不满足双亲委派模型，但是类加载器包括抽象类ClassLoader在JDK1.0就有了，用户本来就是直接覆盖loadClass()方法自定义类加载逻辑，因此只有重写loadClass方法就能破坏调双亲委派机制，而且那时重写类加载逻辑就要重写loadClass方法；

       • 对于该问题，JDK1.2在ClassLoader中添加了一个protected的findClass()方法，引导用户将类加载器逻辑编写到该方法中，而不是直接在loadClass()方法中直接编写代码，将双亲委派的实现编写在loadClass中，在loadClass方法中当父类加载器加载失败，子类加载器再调用findClass()方法来尝试加载，实现既按照用户自己定义的方式去加载字节码二进制信息流，也能保证自定义类加载器是满足双亲委派机制的

     • 2️⃣线程上下文类加载器

       • 双亲委派机制存在缺陷，JDK的核心API总是由顶层的类加载器加载，但是如果核心API想要回调用户类中的代码就无法实现了[核心API需要引导类加载器加载，但是接口的实现需要由系统类加载器进行加载，引导类加载器不认识、无法加载和调用这些应用类]，比如Java的标准服务JNDI的代码有引导类加载器加载，但是JNDI的设计目的就是对资源进行查找和集中管理，需要调用其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口[SPI：Service Provider Interface，Java把核心类rt.jar中提供外部服务可由应用层自行实现的接口称为SPI]，Java为了解决这个问题引入了不太优雅的线程上下文类加载器[Thread Context ClassLoader]设计[默认情况下线程上下文类加载器就是系统类加载器]，

       • 当父类加载器想用子类加载器加载的类时委托线程上下文类加载器去调用子类加载器加载的类，这个过程的目的是父类加载器以线程上下文类加载器为中介去请求子类加载器完成类加载的行为从而实现在引导类加载器加载会调用用户实现类中方法的SPI核心类时由引导类加载器去请求子类加载器尝试加载需要调用的用户类，这个过程违背了双亲委派模型的原则，Java中的SPI比如JNDI、JDBC、JCE、JAXB、JBI都是使用这种方式来实现的，JDK6为了消除这种极不优雅的实现方式，提供了java.util.ServiceLoader类以META-INF/services中的配置信息和责任链模式才给SPI的加载提供了相对合理的解决方案

     • 3️⃣这种方式是由于用户对代码热替换、模块​热部署等对程序动态性的追求导致的，所谓的热部署、热替换就像电脑一样不需要停机就能替换鼠标键盘等外设

       • 2008年IBM主导的JSR-291的项目即OSGI R4.2针对模块化部署的标准把Oracle和SUN公司按在地上摩擦，Oracle公司不服气在Java9引入了jigsaw模块化新特性才渐渐实现了Java模块化事实上的标准，此时OSGI已经比较成熟了，这里主要介绍OSGI实现的热部署

       • OSGI实现模块化热部署的关键是其实现的自定义类加载器机制，让每一个Bundle程序模块都有一个字节的类加载器，这些自定义的类加载器不再满足双亲委派模型推荐的树状结构，采用更进一步发展的更加复杂的网状结构，更换Bundle即更换程序模块时把Bundle连同类加载器一起换掉实现代码的热替换

       • OSGI只针对部分类使用双亲委派模型，其余的类都是在平级的类加载器中进行，OSGI的类加载器设计不符合双亲委派模型原则，而且为了实现热部署带来了很高的复杂度，但是业界技术人员都认为弄懂了OSGI对类加载器的运用才算是掌握了类加载器的精髓

       • 热替换：在不停止服务的前提下通过替换程序文件来修改程序的行为，大部分脚本语言比如PHP天生就支持热替换，只要替换了PHP源文件，无需重启WEB服务器改动就会立即生效；Java中最初不支持热替换，因为修改了类文件无法让系统自动重新加载被修改的类，只能通过自定义类加载器来实现这个功能，此外不同的类加载器加载同一个字节码文件在JVM内部也会认为这是两个完全不同的类。Java可以自定义类加载器，通过自定义类加载器在一定条件下触发对修改后的字节码文件的加载并替换掉旧的Class实例从而实现不停机的情况下程序的热替换，这种多个自定义类加载器实例加载同一个字节码文件生成不同class实例的方式也破坏了双亲委派模式

   • 沙箱安全机制

     • 沙箱安全机制的作用是保证原生的程序运行环境的安全，沙箱就是限制程序运行的一个环境，沙箱机制是将Java程序限定在JVM特定的运行范围中，严格限制代码对本地系统资源如CPU、内存、文件系统、网络的访问，保证代码的有限隔离，防止对本地系统造成破坏，不同级别的沙箱对资源的访问限制不同，所有的Java程序的运行都可以指定沙箱并定制安全策略

     • JVM沙箱安全机制的变更

       • JDK1.0本地代码可以访问一切本地资源，远程代码被认为是不受信任的被限制在沙箱环境中严格限制对本地系统资源的访问

         • 缺陷是影响程序的功能扩展，用户无法实现通过远程代码访问本地系统文件，

       • JDK1.1增加了安全策略，允许用户指定远程代码对本地系统资源的访问权限，受信任的远程资源可以访问本地系统资源

       • JDK1.2增加了代码签名，设置了多个不同的权限组，不管是本地代码还是远程代码都可以统一分配到不同的权限组中分类管理不同代码对本地系统资源的访问权限，不同权限组的权限不同

       • JDK1.6的沙箱安全机制引入了域的概念，域可以分为系统域和应用域，系统域专门负责与系统资源的交互，应用域通过系统域代理对系统资源的访问，JVM中不同的应用域都对应不同的权限，代码会被加载到不同的系统域和应用域中，不同域中的类文件具备当前域的全部权限

      

垃圾回收

• 垃圾回收称GG[Garbage Collection]、垃圾回收器也称GC[Garbage Collector]

1. 垃圾收集方法和垃圾收集算法有哪些以及各自的特点

   • 虚拟机栈不需要垃圾回收，调用方法过程中执行方法入栈，方法执行完毕出栈即可；可以认为95%的垃圾回收集中在堆区，5%集中在方法区[JDK8以后使用元空间本地内存替代方法区，内存大，一般不会出现内存溢出问题]

   • 串行和并行：用户线程和垃圾回收线程不能同时执行，串行即垃圾回收线程只有一条，并行指垃圾回收线程有多条

   • 并发指垃圾回收线程和用户线程可以同时执行[即不会出现所有用户线程出现stop-the-world的情况]

   • 垃圾回收的意义：避免内存被耗尽，清除内存碎片，整理出新的大段内存分配给新的对象，除了Java，C#，Python、Ruby都使用自动内存分配和自动垃圾回收的方式

     • 如果不对内存中的垃圾进行处理，这些垃圾对象会一直保持到应用程序结束，最终可能导致内存溢出

     • 内存泄漏：对象本身不再使用，但是试图回收的时候发现对象还存在指向的引用比如C/C++的忘记释放内存导致没有办法被回收，引用计数算法中没有特意处理循环引用的问题导致内存泄漏，Java中定义的内存泄漏就是用户已经不会再使用某个对象，但是垃圾回收时还是发现可达性分析时对象还是可达的

     • 自动的内存分配和垃圾回收会弱化开发人员的内存溢出时的定位和解决问题的能力，需要使用监控工具对自动化技术实施必要的监控和调节

   • 垃圾回收算法

     • 垃圾标记阶段

       • 引用计数算法

         • 概念：每个对象都有一个整形引用计数器属性，记录对象被引用的次数，每有一个对象引用了该对象，引用计数器就加1，每当一个引用失效，引用计数器就减1，引用计数器的值为0，表示对象不可能再被使用，可以进行垃圾回收，只要发现引用计数器为0，不需要等待内存区域空间不足就会直接回收

         • 优点：实现简单，垃圾对象便于标识，相较于可达性分析算法效率高，回收没有延迟性

         • 缺点：

           • 引用计数器属性增加了内存空间上的开销，每次新增或者销毁对象引用都会对引用计数器进行更新，增加了运行性能开销

           • 引用计数算法最致命的问题是没法处理循环引用的问题，导致Java的垃圾回收器没有使用该算法

             • 循环引用是指比如一个引用指向一个环形链表或者两个对象互相指向彼此，销毁引用时，环形链表中的所有对象都被环形链表中的其他对象引用，因此环形链表并不会被销毁，导致整个环形链表内存泄漏

             • 通过两个对象循环引用也能证明Java没有使用引用计数算法

             • Python使用了引用计数算法，Python解决循环引用的问题主要通过手动解除和弱引用两种方式；手动解除就是显式将循环引用的指针销毁；弱引用是Python提供的标准库，循环引用使用弱引用，只要发现对象引用是弱引用就对对象进行回收

       • 可达性分析算法[根搜索算法、追踪性垃圾收集]

         • 可达性分析算法最重要的就是解决在引用计数算法中出现的循环引用问题，被Java、C#使用

         • 概念：内存中的存活对象都会被根对象集合中的根对象直接或者间接的连接，以根对象集合GC Roots作为起始点，在集合中从上到下从根对象开始搜索，检查根对象引用了哪些对象实体，这些对象实体又引用了哪些对象实体，整个从根对象开始的树上的对象都被认为是存活对象，存活对象被认为是可达的；垃圾对象无法通过根对象访问到，即没有和引用链相连的对象认为是不可达的，被认为对象已经死亡，可以被标记为垃圾对象

           • 根对象集合是一组必须活跃的引用，GC Roots中包含以下元素，判断技巧是如果一个指针指向堆内存中的对象但是又不存放在堆内存中，指针指向的对象就是一个根对象

             • 虚拟机栈中局部变量表中的引用数据类型引用

             • 本地方法栈中引用数据类型引用

             • 类静态属性引用

             • 串池中引用

             • 同步监视器[同步对象]即同步锁持有的对象

             • JVM内部的引用比如基本数据类型对应的class对象，常驻的像空指针、内存溢出等异常对象，系统类加载器

             • 反映虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

             • GCRoots中还有可能加入一些临时的对象，比如只对堆的新生代进行局部垃圾回收，非新生代比如老年代或者其他关联区域的对象也会临时加入到GC Roots中去考虑来保证可达性分析的准确性

           • 从根对象开始搜索走过的路径被称为引用链

           • 可达性分析需要在一个保证一致性的快照中进行，不能一边分析引用关系根节点集合还在不断地变化，因为这点导致GC时必须STW停下所有用户线程，即使是号称不会停顿的CMS低延迟并发垃圾收集器枚举根节点也必须要停顿下来

         • 对象的finalization对象终止机制

           • 目的是允许开发人员在object.finalize()方法中自定义对象销毁之前的额处理逻辑，一般是用于对象在被回收前对计算机资源进行释放，比如关闭文件、关闭套接字和数据库连接等

           • 不要试图去主动调用一个对象的finalize()方法，应该交给垃圾回收器进行调用，原因主要有以下三点

             • 主动调用finalize()方法可能导致对象复活

             • 主动调用finalize()方法也是由fianlizer线程执行，该线程优先级比较低，即使主动调用也不一定会立即被执行，极端情况下不发生GC，finalize()方法没有执行的机会

           • 重写fianlize()方法如果性能太差，或者陷入死循环，会严重影响GC的性能

           • 因为finalize()方法执行时机的存在，JVM中的对象一般有三种可能的状态；一个不可达的对象也不是必须被销毁，在某个条件下不可达对象可能被复活

             • 可触及状态：对象可达

             • 可复活状态：对象所有的引用都被释放，对象不可达，但是对象可能在finalize()方法中被复活

             • 不可触及状态：对象不可达，且finalize()方法被调用后没有复活对象就会进入不可触及状态，此后对象不可能被复活，只要用户不主动调用对象的finalize()方法，该方法在对象生命周期中只会被调用一次

           • 机制流程

             • 如果对象obj到GC Roots没有引用链，进行第一次标记

             • 被标记的对象判断是否有必要执行finalize()方法

               • obj没有重写finalize()方法，或者fianlize()方法已经被虚拟机调用过了，则finalize()方法不会被执行，obj会被判定为不可触及

               • 如果obj重写了finalize()方法且没有被执行过，obj会被插入到F-Queue队列中，由JVM创建的一个低优先级的fianlizer线程触发fianlize()方法的执行

               • finalize()方法执行完GC会对obj进行第二次标记，如果obj在finalize()方法中变得可达，第二次标记时，obj会被移出即将被回收对象的集合；此后一旦obj再次不可达，此时被第一次标记后不会再调用finalize()方法，对象直接变成不可触及状态，然后再被第二次标记直接被销毁

           • MAT的GC Roots溯源

             • 显示GC Roots方面，Jvisualvm没有MAT这么方便，找到GC Roots通过引用链来判断本该被回收的对象哪个位置存在内存泄漏

             • MAT[Memory Analyzer]：是基于Eclipse开发的免费性能分析工具，用于查找内存泄漏以及查看堆内存的消耗情况，和jconcolse、jProfiler、jvisualvm等功能类似

               • MAT可以离线分析通过命令行jmap -dump:format-b,live,file=test1.bin 进程号命令生成或者jvisualVM的监视选项卡下的堆Dump导出的离线dump快照文件[Jvisualvm关闭dump文件就没了，需要另存为才能保存]

               • 通过JVM参数-XX:+HeapDumpOnOutOfMemoryError可以在系统发生OOM时会在当前模块根目录下自动生成以.hprof结尾的dump文件

             • 流程

               • 生成离线Dump文件

               • MAT-File-open File打开dump文件，蓝色图标下拉列表--Java Basics--GC Roots就能看到根对象集合中的所有对象

               • Eclipse对GC Roots中的对象采用了自定义的分类标准，通过线程可以查找当前线程下的所有根对象

           • JProfiler的GC Roots溯源

             • 流程

               • JProfiler可以在Heap Walker中动态显示每个类的对象实例数量，针对某个类点击Show Selection In Heap Walker可以单独展示一个类下的所有对象实例

               • 点击Refernces选项卡，选择Incoming refernces点击Show Paths To GC Root可以展示当前对象对应的根对象

             • 使用JProfiler可以直接打开dump文件

               • 通过Biggest Objects可以查看每个对象的大小，可以直接定位到因为对象太大导致的内存溢出的对象

               • 通过Heap Walker的Thread Dump可以查看哪个线程出现了OOM异常

     • 垃圾清除阶段：执行死亡对象的垃圾回收，释放掉无用对象占用的内存空间

       • 标记清除算法[Mark-Sweep]

         • 1960年提出并被应用到Lisp语言中，堆中有效内存空间被耗尽，STW停止所有用户线程，标记所有垃圾，然后对垃圾进行清除

           • 标记：GC从引用根对象开始遍历，标记所有的可达非垃圾对象，标记会记录在对象的对象头中

           • 清除：GC对堆中所有对象进行线性遍历，将没有被标记的非可达对象进行回收，所谓的清除也只是将需要清除的对象地址保存在空闲地址列表中，为新对象分配内存时判断某块垃圾位置大小是否足够，够就直接覆盖掉垃圾数据，回收实际上回收的是地址，垃圾数据在写入新数据的时候才会清除

         • 优点：容易理解

         • 缺点：

           • 标记遍历所有可达对象时间复杂度O(N)，清除阶段遍历所有对象时间复杂度O(N)，效率相较于其他两种算法不高

           • GC时会停止整个应用程序，用户体验差

           • 清理出来的空闲内存不连续，会产生内存碎片，导致内存不规整为对象分配内存需要维护一个空闲列表

       • 复制算法

         • 1963发布论文并由论文发布者本人引入到Lisp语言的一个实现版本中

         • 原理：准备两块空间可用的内存空间，一次只使用其中一块，垃圾回收时标记阶段将存活的对象规整复制到未被使用的内存块，交换两个内存块的角色完成垃圾收集，新生代的幸存者区就使用的复制算法

         • 优点：

           • 没有标记和清除过程，实现简单，运行高效

           • 垃圾收集后的内存空间规整，不会出现碎片问题

         • 缺点：

           • 需要两倍的内存空间

           • 对象移动后引用地址会发生变化，垃圾回收还需要重新改变引用对应对象的地址值，内存和修改引用上的开销也不小

           • 对于只有少量存活对象的场景表现还行，但是如果极端情况下，所有的对象都存活，此时复制算法相当于把所有对象原封不动重新拷贝到另一块内存空间，而且还要重新改变所有对象的引用地址值，无效开销非常严重；因此复制算法只适用于内存充足且每次垃圾回收存活对象非常少的情况，比如新生代这种死亡率达到70%-99%的内存空间使用复制算法比较合适，也靠频繁的GC来降低双倍内存的开销；像老年代这种对象存活时间久就不适合使用复制算法

       • 标记压缩算法[Mark-Compact、标记整理算法]

         • 标记清除算法能用在老年代，但是对象过大会直接进入老年代，标记清除算法内存碎片太多，如果要使用标记清除算法，本身效率就不高，还要专门对内存进行规整处理

         • 标记压缩算法是在标记清除算法的基础上进行的优化，1970年发布了标记压缩算法，很多现代的垃圾收集器中都使用的标记压缩算法及其改进版本

         • 原理：

           • 标记：从根节点开始标记所有被引用的对象

           • 压缩：将所有存活的对象整理到内存的一端按顺序排放

         • 优点：

           • 内存规整，使用指针碰撞来为对象分配内存无需使用空闲列表来记录空闲内存的地址，消除了复制算法内存减半的高额代价

         • 缺点：

           • 效率低，甚至比标记清除算法还低一些，比复制算法多了一个标记环节，比标记清除算法多了一个垃圾整理环节

           • 需要更改移动后的对象的引用地址

           • 移动过程也需要STW，暂停用户线程的时长也会长一些

       • 分代搜集算法

         • 分代搜集算法不是一个真正的算法，只是基于不同对象生命周期不同策略性地选择不同的搜集方式提高垃圾的回收效率[跟业务挂钩的对象生命周期就会长一些，程序运行期间产生的临时变量生命周期就短一些，不可变类的特性每次更新操作都会创建对象决定了这些类的生命周期比较短]

         • 目前几乎所有的垃圾回收器都是采用分代收集算法实现的，堆区一般分成新生代和老年代两个区域，几乎所有的垃圾回收器都区分新生代和老年代

           • 新生代区域小，对象生命周期短，存活率低，回收频繁；回收频繁要求算法效率高、存活率低对应存活对象少，正好适合使用复制算法；复制算法的弊端内存开销大，通过细分新生代，引入幸存者区屏蔽掉生命周期极短的对象缓解内存浪费；新生代占堆区的1/3，单个幸存者区占新生代的1/10，只有1/30的内存额外开销

           • 老年代区域大，对象生命周期长，存活率高，回收频率低；一般使用标记清除算法和标记整理算法混合实现，CMS是针对老年代的垃圾回收器，基于标记清除算法实现，对于内存碎片问题的解决是当由于内存碎片导致对象分配问题时，补偿使用基于标记压缩算法的Serial Old垃圾回收器执行Full GC整理老年代的内存

       • 增量收集算法

         • 分代收集算法STW的时间比较长，严重影响用户体验和系统稳定性，增量收集算法为了解决STW时间长的问题

         • 原理：

           • 每次垃圾收集线程只收集一小块内存空间，接着继续执行用户线程，依次反复直到垃圾收集完成，即把集中在一块的STW时间分散到一段时间区间内，增量收集算法协调垃圾收集线程和用户线程的执行

         • 缺点：

           • 频繁在垃圾回收线程和用户线程间进行上下文切换，会增加垃圾回收的整体成本，造成垃圾回收器吞吐量的下降

       • 分区算法

         • 分区算法将整个堆空间划分成不同的小区间[region]，每个小区间独立使用，独立垃圾回收，有的小区间作为伊甸园区、有的小区间作为幸存者区，有的小区间作为老年代，有的小区间放大对象；根据GC的指定时间区间可以控制单次垃圾回收回收多少个小区间，降低GC导致的停顿间隔

         • 实际的GC实现过程要复杂的多，前沿GC都是复合算法，并且并行和并发兼备[并行指多个垃圾回收线程、并发指垃圾回收线程和用户线程同时运行]

   • 三种垃圾清除算法的对比[没有最好的算法，都有优缺点，需要根据应用场景选择使用]

     • 速度：复制算法最快、标记清除算法中等、标记压缩算法最慢

     • 内存开销：复制算法需要活对象两倍的开销、标记清除算法和标记压缩算法都是正常开销，标记清除算法有内存碎片，标记压缩算法没有内存碎片

     • 移动对象：复制算法和标记压缩算法都会移动对象，标记清除算法不会移动对象

2. GC对象的判定方法有哪些，即如何判断对象已死亡

   • 垃圾：程序运行期间没有任何指针指向的对象，不够准确，在可达性分析中不可达的对象，即无法通过GC Roots根对象集合中的对象访问到的对象

   • 可达性分析、finalize方法、各类引用关联对象的状态和生命周期

3. 如何判断一个常量是废弃常量

4. 简述GC流程，对象如何晋升到老年代

5. 简述常见垃圾回收器的优缺点，重点阐述CMS和G1[原理、流程、优缺点]

   • GC没有被JVM规范要求必须使用具体的垃圾回收器，很多厂商都有自己的实现，发展至今已经衍生了众多GC版本，JDK每个版本的更新都会提到GC的变化

   • 垃圾回收器的分类

     • 按垃圾回收线程的线程数分可以分为串行和并行垃圾回收器，串行垃圾回收器适合单CPU或者硬件不是特别优越的场合，串行回收器的性能表现比并行或者并发回收器表现更好，串行回收器默认工作在在客户端模式下的JVM中

     • 按照工作模式可以分为并发式垃圾回收器和独占式垃圾回收器，独占式指垃圾回收线程工作时其他用户线程全部暂停；并发式指垃圾回收线程和用户线程交替工作，减少用户线程的单次停顿时间

       • 并发垃圾回收器一次垃圾回收期间部分多段时间只能垃圾回收线程工作，部分时间垃圾回收线程可以和用户线程同时工作

     • 按照碎片的处理方式可以分成压缩式垃圾回收器和非压缩式垃圾回收器，压缩式指垃圾回收完以后是否对存活对象进行规整整理，压缩式垃圾回收使用指针碰撞的方式再分配对象空间，非压缩式垃圾回收使用空闲列表的方式再分配对象空间

     • 按照处理的内存区域可以分为年轻代垃圾回收器和老年代垃圾回收器

       • 新生代垃圾回收器只能回收新生代：Serial、Parallel Scavenge、ParNew

       • 老年代垃圾回收器只能回收老年代：Serial Old、Parallel Old、CMS

       • 整堆收集既可以回收新生代也可以回收老年代：G1

       • JDK8及以前可选择的组合关系：Serial+CMS/Serial Old；ParNew+CMS/Serial Old；Parallel Scavenge+Serial Old/Parallel Old

         • 因为CMS是并发垃圾回收器，垃圾回收的同时用户线程还会继续执行，因此CMS不能等到老年代空间满了再进行回收，如果确实回收晚了或者垃圾制造速度比回收速度快导致CMS垃圾回收失败，此时会选择Serial Old作为后备方案来容错，因此使用CMS需要使用Serial Old作为兜底垃圾回收器

         • JDK8中Serial+CMS和ParNew+Serial Old的组合过时但是还可用，JDK9中这两个组合完全被禁止使用

         • JDK14中Parallel Scavenge+Serial Old过时但是还可以使用，CMS被移除，这是因为JDK9中G1被引入替代了CMS

         • JDK8中的默认组合是Parallel Scavenge+Parallel Old

         • Parallel Scavenge底层使用的框架和CMS不同，导致两个不能组合使用

         • 存在多种不同组合的原因是Java在移动端和服务器端都有很多应用场景、针对不同场景的要求对垃圾回收器的要求不同，没有万能的垃圾回收器，只能选择针对具体应用最合适的垃圾回收器

       

   • GC的性能指标：吞吐量、暂停时间和内存占用三者是相互矛盾的关系，暂停时间的重要性越来越重要，随着硬件技术的发展，内存占用可以越来越大，硬件性能的提升也促进吞吐量的提升，但是内存的扩大也导致STW的时间更长；现在GC优化的重点就是降低STW的时间实现低延迟；针对不同场景具体要求也不同，像Parallel并发垃圾回收器更关注吞吐量、CMS、G1、ZGC更多地关注暂停时间；设计或使用GC算法时必须确定GC是更专注高吞吐量还是低延迟，在二者之间找到一个合适的折中点；像G1的标准是在优先降低暂停时间控制暂停时间的最大值的基础上再考虑提升吞吐量

     • 吞吐量：总运行时间等于程序运行时间加内存回收时间，吞吐量为程序运行时间占总运行时间的比例

       • 吞吐量越高，程序对暂停时间的要求就越低，通过减少GC线程活跃的频率来提升吞吐量会导致单次暂停时间的增加导致高延迟

       • 服务器更看重吞吐量

     • 垃圾收集开销：内存回收时间占总运行时间的比例

     • 暂停时间：单次STW的时间，即执行垃圾收集时用户线程被暂停的时间

       • 暂停时间通过降低每次GC的内存大小，增大GC的频率来实现，总的吞吐量会降低，总的STW时间因为线程上下文切换会增加，因此低暂停时间会拉低吞吐量

       • 200ms的暂停时间都可能打断终端用户的体验，交互式的客户端应用程序更多关注低暂停时间即低延迟

     • 收集频率：垃圾收集的频率

     • 内存占用：堆区大小

     • 快速：对象从诞生到被回收经历的时间

   • 垃圾回收器的发展历史

     • 1999年随JDK1.3发布的串行垃圾回收器Serial，是第一款垃圾回收器，在单核CPU和客户端场景下的性能表现不错；ParNew是Serial的多线程即并行版本，在服务端性能更好一些

     • 2002年随JDK1.4发布Parallel GC和Concurrent Mark Sweep GC[CMS]，Parallel在JDK6成为HotSpot的默认GC，适用于新生代的GC，老年代使用Parallel Old GC；关注低延迟的场景下更多地选择CMS；Parallel和Parallel Old搭配使用，但是不能和CMS搭配使用，CMS可以和ParNew搭配使用；在不同生产环境下，可以使用parallel和parallel Old组合或者ParNew和CMS组合；在硬件性能比较低的场合下才会考虑Serial和Serial Old的组合

     • 2012年随JDK1.7发布了G1，2017年JDK9中G1取代CMS成为HotSpot的默认垃圾回收器，CMS被提示过时且后续将会废弃，2018年G1通过并行垃圾回收来改善垃圾回收器的延迟，实现在限定暂停时间的前提下尽可能提高吞吐量

       • G1的特点是兼具回收新生代和老年代，G1使用的是分区算法

     • 2018年随着JDK11发布引入Epsilon垃圾回收器和实验性的可伸缩的低延迟垃圾回收器ZGC，也称No-op无操作垃圾回收器

     • 2019年JDK12发布在Open JDK中引入了红帽公司研发的Shenandoah GC，该垃圾回收器也是专注于低延迟，同时对G1和ZGC做自动返回未使用对内存给操作系统

     • 2020年随着JDK14的发布删除了CMS垃圾回收器，即使配置了CMS也会使用默认的G1，但是JVM不会报错只会警告，此前ZGC只能使用在Linux系统上，2020年扩展了ZGC可以在mac和windows上使用

   • 七款经典垃圾回收器[所谓经典就是已经被商用检验的]

     • 串行回收器：Serial、Serial Old

     • 并行回收器：ParNew、Parallel Scavenge、Parallel Old

     • 并发回收器：CMS、G1

     • 新时期还在发展中处于实验阶段的垃圾回收器：Shenandoah、ZGC、Epsilon

     • 选择垃圾收集器的策略

       • 客户端或者嵌入式这种内存和CPU资源贫瘠选择Serial

       • 吞吐量最大化选择Parallel

       • 低延迟暂停时间最小化选择CMS

     • 垃圾收集器的选择指标[国内只有像阿里这种需要需要优化底层垃圾收集器的底层算法、一般的程序员只需要关注根据应用场景选择合适的垃圾收集器]

       • 优先调整堆大小让JVM自动调整，不一定特别好但是一定不会差

       • 内存比较小，使用串行GC

       • 单核单机程序，并且没有暂停时间要求使用串行GC

       • 多核、要求高吞吐量、允许暂停时间超过1s，可以选择parallel并行垃圾收集器

       • 多核、低暂停时间、互联网应用这类需要快速响应的场景，选择G1这种并发GC，现在的互联网项目基本都使用G1

     • 小结

       • 新生代都是复制算法、老年代除了CMS是标记清除算法其他都是标记压缩算法

       • 在JDK14及以后能使用的组合只有Serial+Serial Old；Parallel+Parallel Old；G1

       • GC发展阶段：

       GC	工作模式	工作区域	GC算法	侧重	适用场景
       Serial	串行	新生代	复制算法	响应速度	单核CPU的Client模式下
       ParNew	并行				多核CPU的Server模式下与CMS配合
       Parallel				吞吐量	少量交互的后台运算场景
       Serial Old	串行	老年代	标记压缩算法	响应速度	单核CPU的Client模式下
       Parallel Old	并行			吞吐量	少量交互的后台运算场景
       CMS	并行 并发		标记清除算法	响应速度	互联网或者B/S业务
       G1		新生代 老年代	标记压缩算法 复制算法		服务端应用

   • Serial

     • Serial曾经作为HotSpot的Client模式下的默认新生代垃圾回收器，基于复制算法、串行回收和STW机制的串行垃圾回收器

     • Serial还提供用于老年代垃圾收集的Serial Old垃圾收集器，基于标记压缩算法、单垃圾回收线程串行回收和STW，Serial曾经作为HotSpot的Client模式下默认的老年代垃圾回收器，Serial Old在Server模式下主要与Parallel Scavenge组合作为老年代垃圾回收器以及作为CMS的兜底垃圾收集方案

     • 多核CPU场景下依然可以选择Serial，但是效率不高，一般不会这么设置；只有单核CPU场景下才会用，现在客户端设备单核CPU也很少了，基本上只有嵌入式设备才会考虑

     • HotSpot虚拟机可以使用JVM参数-XX:+UseSerialGC指定年轻代和老年代都使用Serial垃圾收集器，注意没有JVM参数-XX:+UseSerialOldGC，使用启动会报错

     • Serial发布古老，设计简单，但是Serial不管是垃圾回收相关数据结构还是垃圾回收线程上的开销都非常小，随着云计算的兴起，在Serverless等新的应用场景下被广泛使用

     • 优点：

       • 单CPU场景下节省了线程上下文切换的开销，单CPU场景下效率相较于其他垃圾回收器更高，适合运行在JVM的Client模式下，适用于交互性较强的场景下

     • 缺点：

       • 因为该垃圾收集器时串行的，暂停时间太长，JavaWeb应用程序完全不会考虑串行垃圾收集器

   • ParNew

     • ParNew是Serial的多线程版本，底层共享了Serial的很多代码，同样在新生代中采用复制算法，STW机制，因为多条垃圾回收线程进行垃圾收集，STW的时间会短一些

     • ParNew曾经作为很多JVM在Server模式下的新生代默认垃圾收集器，后续随着和Serial Old组合在JDK9的过时以及JDK14中CMS的移除几乎落幕，JDK9开始配置在JVM中使用ParNew就会警告不建议使用，在将来会移除

     • 新生代回收频繁，使用并行方式更高效

     • CPU多核场景下ParNew效率更高，单核场景下没有Serial高效，因为线程上下文切换还会有额外的开销

     • 使用JVM参数-XX:+UseParNewGC指定使用ParNew垃圾收集器，该参数只会指定新生代使用ParNew，不会影响老年代；通过JVM参数-XX:ParallelGCThreads可以设置垃圾回收线程的数量，默认垃圾回收线程的数量是CPU的核心数，建议不要超过CPU核心数，避免多个线程竞争同一个核

   • Parallel

     • Parallel和ParNew都一样采用复制算法、并行回收和STW机制，性能上差别也不大；主要区别是parallel的侧重吞吐量，在吞吐量达到一定值以后尽可能提升暂停时间；而ParNew的是在满足指定暂停时间的前提下尽可能提升吞吐量，并且parallel和parallel Old采用的底层框架也不同，导致Parallel和CMS不能组合使用

     • 此外parallel相较于ParNew多了一个自适应调节策略，能够动态调整堆内存分配情况来配合实现高吞吐量

     • 高吞吐量适合不需要太多交互任务的后台运算场景，适合执行批量任务、订单处理、工资支付、科学计算等服务器应用程序

     • Parallel在JDK1.6提供了Parallel Old处理老年代的垃圾收集代替原来适合单核场景下的Serial Old[parallel因为架构问题不能和CMS组合使用]，因为ParNew和CMS搭配比Parallel和Serial Old搭配更好，补上了parallel Old就可以名正言顺的用Parallel，因此Parallel和Parallel Old也是JDK8中Server模式下默认的垃圾回收器

     • parallel Old使用标记压缩算法，基于并行回收和STW机制

     • 相关JVM参数

       • -XX:+UseParallelGC和-XX:+UseParallelOldGC分别是手动指定新生代使用Parallel和老年代使用Parallel Old，只要其中一个被开启，另一个也会自动开启；

       • -XX:ParallelGCThreads设置新生代Parallel的线程数，默认情况下，CPU核数小于8，ParallelGCThreads等于CPU核数；CPU核数大于8，ParallelGCThreads等于(5*CPU核数)/8向下取整后加3，比如12个核心对应10个垃圾回收线程

       • -XX:MaxGCPauseMillis：设置最大暂停时间，为了将暂停时间控制在该指定值内，parallel会自动调整堆大小和其他参数，因为parallel因为注重吞吐量适合在服务端，因此建议谨慎配置该参数，因为该时间设置的比较小，JVM就会自动调小堆内存大小，导致GC频率增高；频率高了多了线程上下文切换的开销以及每次额外工作的开销导致整体吞吐量会下降

       • -XX:GCTimeRatio：设置垃圾收集时间占总时间的比例即设置垃圾收集开销1/(N+1)，设置的是1/(N+1)中的N，默认值为99，即垃圾回收的时间不超过程序运行时间的1%，暂停时间越短越容易超过设定的该参数

       • -XX:+UseAdaptiveSizePolicy：设置parallel启用自适应调节策略，默认情况下该参数就是开启状态，会自动调整年轻代的大小、伊甸园区和幸存者区的比例，晋升老年代对象年龄阈值等参数，期望能尽量满足预设的吞吐量和停顿时间；使用parallel通常会手动指定堆空间的大小

   • CMS[Concurrent-Mark-Sweep]

     • CMS就如同其名字一样是基于标记清除算法实现的HotSpot中第一款真正意义上的并发垃圾收集器，第一次实现了垃圾回收线程和用户线程同时工作；CMS也会有STW

     • CMS的关注点是保证暂停时间的前提下尽可能提升吞吐量，非常适合互联网站或者B/S系统的服务端这类特别注重请求的响应速度的场景

     • 因为CMS和Parallel底层框架不兼容，使用CMS回收老年代时，新生代只能选择ParNew或者Serial中的一个；在JDK9兼具并发并行特点的G1发布前，CMS的使用非常广泛，至今仍然有很多系统在使用CMS

     • 工作原理：

       • 1️⃣：单个垃圾回收线程进行初始标记，此时会STW，持续时间非常短

         • 初始标记的任务是标记出GC Roots直接关联的根节点对象，因为只是对根节点对象进行标记，因此这个环节执行速度非常快

       • 2️⃣：单个垃圾回收线程执行并发标记，此时不会STW

         • 并发标记的任务是从根节点对象开始遍历所有存活对象，该过程耗时长但是不需要暂停用户线程

       • 3️⃣：多个垃圾回收线程执行重新标记，此时会STW

         • 因为用户线程在并发标记过程仍然会运行，因此并发标记完成后GC Roots和原本部分存活的对象可能产生变化，JVM采用的是三色标记法，完全没有被GC访问过的对象会被标记为白色，被GC访问过但该对象直接引用到的其他对象没有全部访问成功被标记为灰色，对象以及其直接引用的其他对象都被GC访问到被标记为黑色，在初始标记和并发标记期间一些对象的直接对象因为还没来得及被创建被标记为灰色，被标记为黑色和灰色的对象都不会被回收，在并发标记期间因为引用关系变化还可能涉及到多标和漏标，

         • 多标是对象已经被标黑或者标灰，但是在并发标记期间引用被断开变成不可达对象，这就是浮动垃圾，此外并发标记开始后创建的新对象会被直接标记为黑色，如果这部分对象在并发标记期间变成了垃圾也会直接变成浮动垃圾，浮动垃圾本轮GC不会被清除，需要等到下一轮垃圾回收才会被清除，浮动垃圾也不会影响到垃圾回收的正确性；

         • 漏标是并发标记过程灰色对象直接或间接断开白色对象的引用，黑色对象重新直接或间接引用被断开的白色对象，同时满足这两个条件由于GC不会再去遍历已经被标黑的对象，这些白色对象在本轮GC因为已经被灰色对象断开无法再被GC访问，无法被标黑或者标灰，如果不进行处理这些对象会被当做垃圾回收，这会直接影响用户程序的正确性，是不可接受的；解决办法是并发标记期间对象引用被断开又被其他对象引用时将该对象放入特定的集合，并发标记结束后停止所有用户线程遍历重新标记集合中的对象；CMS通过写屏障加增量更新[当对象有新引用插入时记录下新的引用对象等待遍历重新标记]的方式通过黑色对象重新引用白色对象记录下对象破坏对象被漏标的第二个条件；G1通过写屏障加原始快照SATB，当灰色对象断开白色对象的引用时记录白色对象到特定集合中等待被重新标记破坏对象被漏标的第一个条件，本质还是让垃圾回收按照并发标记前的快照来执行垃圾回收，应该被清理的垃圾当做浮动垃圾处理；ZGC是通过读屏障的方式在读取对象的成员变量还没到断开引用就记录下该成员变量等待遍历重新标记破坏对象被漏标的第一个条件

         • 重新标记的任务是对可能发生漏标的对象进行重新标记，多标的对象或者并发标记过程新产生的对象变成垃圾一律当做浮动垃圾等待下一轮GC再清理，重新标记过程会STW，但是停顿时间比初始标记阶段稍长，但是远比并发标记阶段时间短

         • 这里有两篇三色标记算法和增量更新的博客，闲了再看看，12.垃圾收集底层算法--三色标记详解，一文读懂-JVM三色标记法与读写屏障

       • 4️⃣：单个垃圾回收线程执行并发清除，此时不会STW

         • 并发清除阶段的任务是清理掉标记阶段判定死亡的对象，因为不需要移动存活的对象，因此用户线程可以同时执行

       • 5️⃣：单个垃圾回收线程执行重置线程，此时不会STW

     • 特点：

       • 只有并发标记和重新标记两个阶段进行了STW，暂停时间非常短，目前没有任何一款GC能做到完全不需要STW

       • 因为垃圾回收期间用户线程还会继续执行，因此CMS开始回收时需要确保用户线程有足够的内存可以使用，此前的垃圾回收器都是内存区域几乎满了再收集，而CMS是堆内存使用率达到某一阈值就开始垃圾回收；如果CMS垃圾回收期间预留的内存无法满足用户线程的需要，会出现Concurrent Mode Failure失败，此时JVM将会临时启用Serial Old来替代CMS进行老年代的垃圾收集，此时会远远增大暂停时间

       • 因为CMS基于标记清除算法，因此只能使用空闲列表执行对象内存分配，CMS因为垃圾回收期间需要用户线程继续执行，因此如果使用标记压缩算法，规整对象的过程就必须暂停用户线程，这就会极大地增加STW的时间

       • CMS因为算法设计上的缺陷，目前用户群体虽然多，但是在JDK9被标记为过时，JDK14中被移除

     • 优点

       • 并发收集，STW时间极短，垃圾收集导致的延迟低

     • 缺点[为了达到低延迟在更频繁的Full GC和固有的浮动垃圾内存占用两方面做了很大的牺牲，因此后面引入了基于分区算法的G1解决CMS的问题并替换CMS]

       • 产生内存碎片，可能导致大对象无法存入老年代不得不提前触发Full GC，导致更频繁的Full GC

       • CMS对CPU资源非常敏感，并发阶段垃圾回收线程会占用CPU资源，垃圾收集期间系统的性能和请求的吞吐量会降低

       • CMS无法处理浮动垃圾，本轮GC并发标记阶段产生的浮动垃圾无法被CMS重新标记，这些在并发标记阶段产生的所有新垃圾都会被留到下一轮GC被处理，因此堆中有一部分空间始终会被浮动垃圾占用

         • 浮动垃圾：多标的对象就是浮动垃圾

     • CMS相关JVM参数

       • -XX:+UseConcMarkSweepGC：手动指定老年代使用CMS垃圾收集器，开启该配置将自动配置-XX:+UseParNewGC在新生代使用ParNew垃圾回收器，同时会自动启用Serial Old作为CMS的兜底垃圾收集器

       • -XX:CMSInitiatingOccupancyFraction：设置堆内存使用率CMS垃圾回收阈值，在JDK5及以前默认值为68，老年代的空间使用率达到68%就会执行一次CMS回收，JDK6及以后默认值为92；内存增长缓慢的情况下可以设置一个比较大的阈值，能有效降低CMS垃圾回收的触发频率；如果应用程序的内存增长非常快，应该设置一个比较低的阈值，避免频繁触发Serial串行垃圾收集器，显著降低Full GC的执行机会

       • -XX:+UseCMSCompactAtFullCollection：指定在执行完Full GC后对内存空间进行压缩整理

         • 注意Serial Old、Parallel Old、G1都能执行Full GC，JVM默认使用Serial Old执行Full GC，使用其他两种垃圾回收器由对应垃圾回收器执行Full GC

         • 注意Full GC可以选择压缩也可以选择不压缩

       • -XX:CMSFullGCsBeforeCompaction：设置在执行多少次不压缩的Full GC后对内存空间进行压缩规整

       • -XX:ParallelCMSThreads：设置CMS的垃圾收集线程数量。CMS的默认垃圾收集线程数是(ParallelGCThreads+3)/4，其中ParallelGCThreads是新生代并行垃圾收集器的垃圾收集线程数量，CPU资源紧张时，受CMS垃圾收集线程的影响，应用程序的性能在垃圾收集期间表现可能非常糟糕

   • G1

     • G1的设计思想是区域化分代式，在吞吐量方面parallel性能表现不错，在暂停时间方面CMS表现不错，随着内存和CPU的进一步发展和庞大复杂用户数越来越多的业务要求，需要更适应现代要求的更低暂停时间和更高吞吐量的垃圾收集器；G1的设计目标是延迟可控的情况下尽可能提高吞吐量，基于分区算法能同时回收新生代和老年代的并行全功能垃圾收集器；主要针对配备多核CPU和大容量内存的服务端应用机器，具备极高概率满足GC停顿时间的同时还兼具高吞吐量的特性；在JDK7移除了实现性标识，使用-XX:+UseG1GC来配置启用，在JDK9被设置为默认垃圾收集器

     • G1的原理

       • G1将堆分割为物理上不连续的很多不相关大小一致且在JVM生命周期中大小不会发生改变的Region区域，使用不同的Region表示伊甸园区、幸存者0区、幸存者1区和老年代，这些区域逻辑上也不再是连续的区域了

         • 单个Region只能属于伊甸园区、幸存者区或者老年代中的一个角色，此外G1还增加了新的内存区域Humongous，用户在Humongous中存储超过0.5个region的大对象，一个Humongous的默认大小就是一个region的大小，如果一个H区放不下一个大对象，G1会组合连续的H去来存放大对象，如果找不到能够存放该大对象的逻辑上连续的H区[注意H区存放大对象只要求H区逻辑上连续即可，其他的垃圾回收器大对象和普通对象一样也要求物理上是连续的]，此时就会直接启动Full GC，在逻辑上H区从属于老年代；大对象因为新生代放不下会直接放在老年代，但是一个短期存在的大对象随着老年代一起GC会长时间无效占用堆内存，

         • JVM维护了一个空闲列表记录空白的Region，空闲列表中的Region被使用时可以变换成任意一种角色

         • 因为Region之间使用复制算法进行垃圾回收，因此Region内部自然而然使用指针碰撞的方式为对象分配内存；此外单个Region中也会分配TLAB

       • G1会跟踪各个Region的垃圾回收可以获得的空闲空间大小以及回收需要时间的经验值，在后台维护一个优先级列表，每次根据允许的收集时间优先去回收价值最大的Region，因为这种设计方式侧重于回收垃圾最大量的区间，因为该垃圾收集器被命名为Garbage First

     • 特点

       • 兼具并行与并发

       • 兼顾新生代和老年代垃圾收集：G1仍然属于分代型垃圾收集器，会区分新生代和老年代，新生代中依然区分伊甸园区和幸存者区，但是不要求每个区域在逻辑上连续，也不坚持每个区域固定大小和固定数量；而且支持一个Region动态地扮演单独一个不同种类的分代区域；只是基于分区算法兼顾回收新生代和老年代

       • 空间整合：Region之间通过复制算法进行垃圾回收，整体上可以看做由复制算法实现的标记压缩算法，避免了内存碎片，尤其当java堆非常大的时候，G1的优势会非常明显

       • 可预测的停顿时间模型[软实时soft real-time]：该停顿时间模型能让使用者在明确指定长度为M毫秒的时间片段内，垃圾收集的时间不超过N毫秒，吞吐量对应(M-N)/M；G1只选择部分区域进行垃圾回收，也不需要再所有用户线程全部暂停，按照Region回收价值的大小，维护一个优先级队列，每次根据指定的暂停时间，动态地选择几个回收价值最大的Region进行垃圾回收，保证在有限的垃圾回收时间内获取尽可能高的收集效率；G1不一定能做到CMS在最好情况下的低延迟，但是最差情况要比CMS好很多；软实时指的是不要求垃圾回收时间必须小于指定时间，而是指有一定的把握在指定时间内完成

       • G1提供YoungGC、Mixed GC和Full GC三种垃圾回收模式，分别在不同条件下被触发

       • 除G1外的其他垃圾收集器都使用专门的优先级更低的垃圾收集线程执行并行GC，G1可以在垃圾回收线程处理速度慢的情况下自动调用应用线程来加速后台的GC工作

       • G1随着JDK版本迭代不断地改进，在JDK10中将串行的Full GC改成了并行Full GC，很多场景下表现都会略优于Parallel的并行Full GC

     • 使用场景

       • 大内存、多处理器机器的服务端应用，普通大小的堆中表现平平；为低GC延迟的大堆应用提供垃圾回收方案

         • 当堆大小大于6GB，暂停时间可以低于500ms，通过每次只清理一部分region的增量式清理保证每次GC的暂停时间不会过长

       • 适合使用G1替换CMS的场景：

         • 超过50%的Java堆空间都是活跃数据

         • 新对象分配频率或者对象年龄提升频率很高

         • GC暂停时间长于0.5s-1s

     • 缺点：

       • G1不能全方位碾压CMS，G1为了垃圾收集产生的相较于其他垃圾收集器额外10%-20%的内存占用，在垃圾收集带来的额外执行负载方面也比CMS高，运行经验表明G1在超过6-8G的大内存应用上具备优势，内存越大优势越大；在小于6-8G的小内存应用上CMS的性能表现大概率会比G1更好

     • G1相关JVM参数

       • -XX:+UseG1GC：在JDK8或JDK7想使用G1需要显示配置

       • -XX:G1HeapRegionSize：设置每个Region的大小，值可以写1-32之间的二次幂，即1、2、4、8、16、32，单位是MB；Region大小设置的一般目标是按最小Java堆划分成约2048个区域，默认值是堆内存的1/2000，但是如果计算得到Region的大小小于1M就会自动取1M

       • -XX:MaxGCPauseMillis：设置期望的最大GC暂停时间，默认是200ms，JVM会尽力实现，但是不能保证每次都达到；一般暂停时间几十毫秒到300ms都是正常的；如果暂停时间设置的过小比如小于50ms，会降低每次垃圾回收的Region数量，增大GC的频率提高响应速度降低吞吐量；吞吐量降低可能导致GC的速度跟不上垃圾产生的速度导致堆被占满触发Full GC

       • -XX:ParallelGCThread：G1并行过程会出现STW，设置并行阶段垃圾回收线程的数量，最大值为8

       • -XX:ConcGCThreads：设置并发标记的线程数，一般设置为ParallelGCThread的1/4

       • -XX:InitiatingHeapOccupancyPercent：设置触发并发GC周期的Java堆占用率阈值，超过该阈值会触发GC，默认值是45即堆总大小的45%

       • 使用G1进行调优开发人员只需要开启G1、设置堆的最大内存、设置最大暂停时间MaxGCPauseMillis，剩下的都交给JVM自动控制

     • 垃圾收集流程

       • G1的一次垃圾回收过程必须包含YGC、老年代并发标记[该环节也会同时进行YGC]、混合回收[Mixed GC涉及到新生代和老年代共同回收的流程所以叫混合]三个环节；如果有需要会继续第四个串行独占高强度的Full GC[JDK10以前FullGC是串行的，JDK10提供了并行FullGC但仍然是独占式的，且暂停时间不可控，不管是什么垃圾回收器都要尽可能避免Full GC]，Full GC是针对GC评估失败后提供的一种保护机制，类似于CMS回收失败替换成Serial Old执行垃圾回收进行兜底；正常情况下都不会出现Full GC，出现FullGC一般就需要进行系统的调优来避免再次出现Full GC

       • 1️⃣YGC：伊甸园区用尽时触发YGC，幸存者区会跟着YGC被动回收，G1在YGC阶段是一个并行独占式垃圾收集器，会暂停所有用户线程，垃圾回收线程并行对年轻代进行垃圾回收；伊甸园区仍然存活的对象存入幸存者区，幸存者区达到年龄阈值的对象移动到老年代，伊甸园区移动到幸存者区的大对象幸存者区放不下也会直接移动到老年代，YGC在整个垃圾回收周期包括Full GC期间都能随时因为伊甸园区满了自动触发

         • YGC时G1会停止所有用户线程的执行，G1创建回收集Collection Set，将年轻代伊甸园区和幸存者区的所有内存分段全部加入到回收集中等待被垃圾回收

         • 伊甸园区和幸存者区的存活对象通过复制算法保存到空闲的region中，该region成为新的幸存者区，幸存者区中达到年龄阈值的对象保存到空闲列表region或者老年代中，该空闲Region成为老年代，原来的伊甸园区和幸存者区成为空闲区域、

         • YGC的流程细节：

           • 1️⃣扫描根：根指的是静态变量、局部变量表中的引用数据类型引用，RSet中记录的外部引用，根作为扫描存活对象的入口

           • 2️⃣更新RSet：处理脏卡队列[dirty card queue，老年代中的对象引用年轻代中的对象通过写屏障和记忆集记录老年代对象的引用不是直接实时地将老年代对象引用记录在记忆集中，因为更新RSet需要多个线程同步，开销比较大，而是设置一个脏卡队列，当引用赋值语句执行时将属性所属对象封装成卡入队列，等到YGC前对脏卡队列中的所有卡进行处理并更新记忆集RSet，不在引用赋值语句处更新RSet是为了用户线程的性能考虑]中的卡来更新RSet，处理后的记忆集才可以真实实时反映哪些老年代对象引用了当前region中的对象

           • 3️⃣处理RSet：识别仍然被老年代对象引用的新生代中的对象，这些对象被认为是存活对象

           • 4️⃣复制对象：伊甸园区存活的对象被复制到幸存者区，幸存者区中存活的对象如果年龄没有达到阈值，年龄自增；达到年龄阈值的存活对象被复制到老年代，如果幸存者区空间不够，伊甸园区的部分对象也会直接晋升老年代

           • 5️⃣处理引用：处理软引用、弱引用、虚引用、终结器引用、JNI弱引用，最终让原来的region区域置空，数据被复制到的region成为新一轮的伊甸园区和幸存者区

       • 2️⃣并发标记：当堆内存使用率达到45%时触发老年代并发标记过程，期间仍然会触发YGC

         • 流程细节

           • 1️⃣初始标记：标记GCRoots中的所有根节点对象，触发一次YGC，初始标记阶段是STW的

           • 2️⃣根区域扫描：​G1扫描幸存者区指向老年代的引用，并标记这些引用指向的老年代对象，根区域扫描阶段不会STW，但是必须在YGC开始之前完成前完成根区域扫描

           • 3️⃣并发标记：使用可达性分析算法对整个堆进行并发标记，此过程不会STW，但是可能被YGC中断，期间如果发现一个region中的所有对象全是垃圾，该region会立即被回收，并发标记过程中会计算每个region的对象活性即区域中存活对象的比例，该对象活性用优先级队列评估回收价值最高的region

           • 4️⃣再次标记：和CMS一样，并发标记阶段用户线程也在执行，需要对可能漏标的对象进行修正，CMS使用写屏障加增量更新的方式来破坏漏标的第二个条件白色对象被黑色对象再次引用无法被察觉的条件，G1使用更快的写屏障加初始快照算法SATB破坏漏标的第一个条件白色对象被灰色对象断开无法被察觉的条件，该阶段会STW

           • 5️⃣独占清理：计算各region的垃圾收集价值并根据回收价值进行排序，识别可以混合回收的区域，为混合回收阶段做准备；这个阶段不会做垃圾的收集，该阶段会STW

           • 6️⃣并发清理阶段：识别和清理全是垃圾的region，此时region中还有存活对象的不会被回收

       • 3️⃣混合回收：并发标记完成后马上开始混合回收过程，G1规整老年代的存活对象到空闲的Region，这些Region也会被自动分配为老年代，该过程因为要尽可能满足指定的暂停时间只会挑选垃圾收集价值最高的几个老年代Region进行垃圾回收,期间仍然会触发YGC

         • 含有存活对象且垃圾占有内存空间超过65%[可以通过JVM参数-XX:G1MixedGCLiveThresholdPercent进行配置，默认值为65%，存活对象超过35%被认为存活对象占比太高，会带来更多的不必要的复制开销且会消耗更多的时间]的老年代region默认情况下会被分8次被回收，优先回收回收价值最高的region，回收次数可以通过JVM参数-XX:G1MixedGCCountTarget设置，而且只有region才会被回收

         • 混合回收的回收集中包含1/8的未被回收的老年代region，全部的新生代region，采用和年轻代回收一样的流程进行垃圾回收，只是多了回收已经被标记存活对象的老年代region

         • 混合回收不一定必须要进行8次，如果JVM发现可以回收的垃圾占堆内存的比例低于阈值10%，就会停止混合回收，该阈值可以通过JVM参数-XX:G1HeapWastePercent设置，默认值是10，意思是允许整个堆内存有10%的空间被浪费，避免花费很多的时间进行GC但是回收的内存却很有限

         • 混合回收阶段Oracle有考虑设计成和用户线程一起并发执行，但是实现起来比较复杂，选择将该特性放到ZGC中去实现

       • 4️⃣Full GC：因为Full GC是串行独占暂停时间不可控的GC，性能非常差且暂停时间很长，G1的设计初衷就是避免Full GC

         • 导致G1进行Full GC的原因：

           • YGC前老年代的可用连续空间小于前几次年轻代晋升老年代的平均大小会直接将YGC替换成Full GC，方法区空间满了时[概率小，因为方法区使用的是本地内存，空间很大]

           • 调用System.gc()时会建议系统执行FullGC，系统会根据运行情况自行判断是否执行Full GC

           • 混合回收完成前老年代的空闲空间已经被耗尽，此时就会使用Full GC暂停所有用户线程来进行兜底垃圾收集[比如暂停时间设置的太短，回收频率变高，但是如果垃圾回收的速度跟不上垃圾产生的速度内存最终还是会被耗尽并触发Full GC]

       • 一般正常情况下，一个最大堆内存4G的Web服务器，每分钟响应1500个请求，每45秒新分配大约2G内存，G1约每45秒执行一次年轻代回收，每31个小时整个堆的使用率达到45%，并发标记完成后执行四到五次混合回收，仅供参考

     • 记忆集[Remembered Set、RSet]：

       • G1相较于其他垃圾回收器需要额外的10%-20%的内存空间来维护一个记忆集，GC的基础是可达性分析，但是YGC只回收新生代中的对象，如果我们进回收新生代中的对象还要将所有对象都遍历一遍判断新生代中的对象是否是可达的[因为新生代的对象可能仅被老年代的对象引用]，回收新生代不得不扫描老年代，这是非常高昂且多余的开销；在其他的分代收集器中也存在这样的问题，但是G1不仅分代而且分Region，而且G1主要应用在大堆，堆越大可达性分析访问的对象就越多，无用的开销也越严重，会严重降低Minor GC的效率

       • 无论是在G1还是其他分代垃圾收集器，JVM都是通过记忆集RSet来避免全局扫描，G1给每个region都配置一个RSet，如果当前region中的对象A同时被两个不同region中的对象B和C引用，就会将两个对象的引用地址记录在RSet中；每次引用数据类型写操作时都会产生一个写屏障中断写操作，检查被引用的对象和当前对象是否在同一个region中[其他垃圾收集器是检查两个对象是否一个处于年轻代，一个属于老年代]，如果不在同一个region中会将当前对象记录到被引用对象所在region对应的RSet记忆集的具体实现卡表CardTable中

       • 进行垃圾回收时，将RSet中的引用作为GC Roots的枚举范围，就能实现不进行全局扫描也不会出现存活对象被漏标

       • 回收老年代的时候不需要特别关心记忆集的问题，因为回收老年代本身就要回收年轻代，回收老年代就相当于全堆扫描

     • 注意事项：

       • 要避免使用-Xmn或者-XX:NewRatio等JVM参数显式设置年轻代的大小，固定年轻代的大小会导致期待的最大GC暂停时间参数-XX:MaxGCPauseMillis失效，交给JVM自己控制就好

       • 不要将暂停时间设置的太短，因为更短的暂停时间会导致更频繁的垃圾回收带来更多的额外如线程上下文切换的开销，导致吞吐量下降，G1设计的吞吐量目标是90%的用户程序执行时间和10%的垃圾回收时间

   • Epsilon

     • JDK11引入，无操作GC，只做内存分配，不做垃圾回收，只适用于一次性运行完一小段程序就退出的场景

   • ZGC

     • JDK11引入，可伸缩的低延迟垃圾回收器，侧重低延迟，ZGC的设计目标是在对吞吐量不造成大影响的前提下实现任意堆大小情况下都将垃圾收集的暂停时间限制在10ms内，ZGC也基于Region分区算法，不设置分代，使用读屏障、染色指针和内存多重映射等技术实现可并发的标记压缩算法

     • 官方文档对ZGC的介绍https://docs.oracle.com/en/java/javase/12/gctuning/

     • ZGC工作过程的四个阶段并发标记-并发预备重分配-并发重分配-并发重映射都是并发的，只在初始标记阶段进行STW，停顿时间几乎就消耗在初始标记上

     • 测试数据

       • 在保证暂停时间不超过10ms的条件下ZGC的吞吐量略低于Parallel，略高于G1，只有1%-2%的差距；如果不保证暂停时间不超过10ms，ZGC的吞吐量相较于Parallel和G1有将近50%的提升

       • 在暂停时间方面，ZGC吊打parallel和G1，平均和99%暂停时间只有1-2ms，即使是最大暂停时间也能控制在10ms内，而parallel和G1的平均暂停时间都在200-300ms之间，G1的平均暂停时间和parallel差不多，但是在最差表现比parallel差很多，G1适合大堆场景

     • ZGC的测试数据相当亮眼甚至达到革命性的要求，未来会作为服务端大内存低延迟应用的首选垃圾收集器

     • JDK14中ZGC被扩展到可以在macOS和windows上使用，此前只能在Linxu上使用，在mac或windows上使用ZGC需要配置JVM参数-XX:+unlockExperimentalVMOptions -XX:+UseZGC，前一个参数表示解锁实验性的JVM参数

   • Shenandoah

     • RedHat公司开发，OpenJDK12引入，侧重低延迟，第一款不由Oracle公司领导开发的HotSpot垃圾收集器，商业版的OralceJDK不愿意引入别人的垃圾收集器，Oracle号称openJdk和oracleJDK没有区别，结果免费开源的openJDK竟然功能还比oracleJDK更多，Shenandoah在2014年被RedHat捐赠给openJdk

     • Shenandoah团队号称Shenandoah暂停时间与堆大小无关，不管将堆设置成多少都有99.9%的把握把垃圾收集的暂停时间限制在10ms内，但是实际使用性能还是取决于堆的大小和工作负载；2016年红帽使用ElasticSearch对200GB的维基百科数据进行索引并发表论文数据：暂停时间确实相较于其他垃圾收集器有质的飞跃，在其他垃圾收集器总停顿时间达到十秒左右的情况下总停顿只有320ms，在其他垃圾收集器的最大停顿时间都是1-4秒的情况下只有89.79ms，平均停顿时间在其他垃圾收集器450-850ms的情况下只有53ms，但是没有实现停顿时间在10ms内，在吞吐量相较于其他垃圾收集器出现了明显下降，以下是测试数据

       GC	运行时间	总停顿	最大停顿	平均停顿
       Shenandoah	387.602s	320ms	89.79ms	53.01ms
       G1	312.052s	11.7s	1.24s	450.12ms
       CMS	285.264s	12.78s	4.39s	852.26ms
       Parallel Scavenge	260.092s	6.59s	3.04s	823.75ms

     • 低延迟方面很厉害，但是吞吐量也断崖式下跌，ZGC性能上比Shenadoah更好一点

     • JDK12新特性尚硅谷视频对Shenandoah有进一步介绍

   • 其他厂商的垃圾收集器

     • AliGC：TaobaoJVM使用的是Ali自己开发的AliGC，基于G1的算法面向大堆场景的垃圾收集器，特定场景下停顿时间比G1要短

     • ZingGC：https://www.infoq.com/articles/azul_gc_in_detail

      

6. 概念简述

   • System.gc()：

     • 通过显式调用System.gc()[里面实际调用的就是Runtime.getRuntime().gc()]或者Runtime.getRuntime().gc()[这个方法是一个本地方法]触发的是Full GC，同时对堆和方法区进行垃圾回收，System.gc()调用附带无法保证对垃圾收集器绝对调用的免责声明，经过测试事实上是否执行也是随机的

       • 但是在调用System.gc()以后再调用System.runFinalization()会强制确保调用失去引用的对象的finalize()方法

     • 因为垃圾回收是自动的，因此一般不需要用户手动调用，但是在特殊场景下比如性能基准测试，在做测试前先做一个GC，防止测试过程中因为内存的原因对测试结果造成影响导致结果不准确

     • 方法中的非静态代码块中定义的局部变量出了代码块仍然存在于局部变量表中，此时GC不会将对应的变量进行回收，按理说局部变量的作用域只在代码块内部，出了代码块局部变量表中的数据就应该被销毁；但是实际上需要后续变量复用局部变量表中失效变量的slot空间时将对应变量值覆盖掉引用才会断掉，此时此前已经结束的代码块中定义的对象才会被垃圾回收器回收

     • 方法弹栈也会导致局部变量表中的引用断掉，此时对象没有引用指向也可以进行垃圾回收

   • Java层面的内存溢出和内存泄露：

     • GC一直在发展，一般情况下不太容易发生OOM，除非垃圾回收器的回收速度低于占用内存的增长速度

     • 报OOM以前一定会进行一次独占式的Full GC

     • JavaDoc对内存溢出的解释：没有空闲内存，且垃圾收集器GC后也无法提供更多的内存

       • 没有空闲空间主要有两个原因

         • JVM的堆内存设置的太小，通过JVM参数-Xms和-Xmx来调整

         • 程序中创建了大量大对象，且长时间因为被引用不能被GC回收，像JDK6以前永久代理的字符串常量池回收不积极就容易发生永久代内存溢出，此时添加新依赖，运行时创建大量动态类，intern方法调用太随意，都很容易发生永久代的内存溢出；永久代替换成元数据区以后这个问题得到改善

       • 报OOM以前一定会触发一次Full GC

         • 清理死亡对象，尝试回收软引用指向的对象、NIO的API也会自动调用System.gc()清理空间，清理以后还是内存溢出就直接抛OOM异常

       • 特殊情况下内存溢出JVM能确定调用垃圾收集器不能解决问题会直接抛OOM，不会再触发垃圾回收，比如超大对象超过堆的最大容量不会尝试进行垃圾回收而是直接抛OOM异常

     • 内存泄漏的解释：对象不会再被程序用到，但是GC又不能回收的对象

       • 实际情况中一般是因为一些不好的实践，比如像引用计算算法中的循环引用问题导致的泄露类似的情况导致的内存泄露完全是出于疏忽或者考虑不完全导致的，由比如将局部变量定义成成员变量或者类变量，将没有必要设置成会级别的数据设置成了会话级别；一般都是忘记断开引用

       • 内存泄露的问题在于因为无法回收或者无法及时回收会慢慢增长占用的内存，直到所有内存耗尽

       • 内存泄露举例：

         • 单例模式：单例对象的生命周期和应用程序一样长，单例独享如果持有外部对象的引用，外部应用无法被回收从而产生内存泄露

         • 提供close()方法执行关闭操作的资源：像网络连接和IO通道必须手动调用close()方法关闭，否则也会因为无法回收而导致内存泄漏

         • TLAB存不下新对象重新从伊甸园区为线程分配一块新的TLAB，旧的TLAB的剩余空间不会再继续使用，而且单个TLAB本身空间就比较小只占伊甸园区的1%还要除以线程总数，很容易就会出现剩余空间无法存放新对象的情况，TLAB的内存浪费现象比较严重，这会导致JVM运行过程中始终有一部分内存无法被使用，为此JVM使用最大浪费空间对TLAB进行约束，当TLAB剩余空间存不下新对象且剩余空间小于最大浪费空间，TLAB所属线程会向JVM申请一块新的TLAB区域存储新对象，如果新TLAB仍然存不下，对象会被直接分配到伊甸园区；如果当前TLAB的剩余空间大于最大浪费空间，对象会被直接分配到伊甸园区；默认最大浪费空间的JVM参数TLABRefillWastePraction为64，表示值为TLAB大小的1/64

   • STW：

     • GC过程中会产生停顿，停顿过程中所有的用户线程都会被暂停，效果就像应用程序卡死了

     • 为什么需要STW：

       • 可达性分析算法中枚举根节点需要暂停所有用户线程来保证分析前后数据的状态一致性，如果不暂停用户线程就可能导致分析过程中对象引用关系不断变化，无法保证分析结果的正确性

       • 所有的垃圾回收器包括G1、CMS、ZGC都有STW事件，只能说随着垃圾回收器的发展，性能更优秀，停顿时间更短；以至于现在衡量一个垃圾回收器的两个指标就是吞吐量和低延迟

       • 设置一个用户线程Thread.sleep()每隔1毫秒打印打印一次。当发生full gc时，打印间隔会有20-150ms的变化

   • 垃圾回收的并行与并发：

     • 线程并发[concurrent]：不是多人一起走，单人就是单核，单个核交替执行多个任务导致用户以为多个任务在同时进行

       • 并发多个任务一起相互抢占资源

     • 线程并行[Parallel]：多个人一起走，多人即多核，真正的多个任务同时刻一起执行

       • 并行多个任务之间不会互相抢占资源

     • GC串行：单条垃圾收集线程串行工作，用户线程此时处于暂停状态，Serial和Serial Old是两个典型的串行垃圾回收器

     • GC并行：多条垃圾收集线程并行工作，用户线程此时处于暂停状态，ParNew、Parallel Scavenge、Parallel Old是三个典型的并行垃圾回收器

     • GC并发：垃圾回收线程和用户线程同时执行，但不一定完全没有STW，用户线程和垃圾回收线程也可能交替执行；CMS和G1是典型的并发垃圾回收器

   • 安全点与安全区域：

     • 安全点：用户线程只能在特定的位置才能停顿下来开始进行垃圾回收，这些位置就称为安全点，安全点就是线程指令中执行时间比较长的某些指令位置

       • 安全点太少GC等待的时间太长，垃圾回收不及时；安全点太频繁可能导致运行时的性能问题

       • 大部分指令的执行时间都非常短，在执行很快的指令处停下来也会影响性能，一般会选择执行时间较长的指令位置作为安全点，比如方法调用[压入栈帧比较耗时]、循环跳转、异常跳转等

     • GC时让线程停顿在安全点的方式

       • 抢先式中断：先统一中断所有线程，某些线程不在安全点就恢复线程让线程继续执行到安全点，目前没有虚拟机采用抢先式中断

       • 主动式中断：JVM设置一个中断标志，每个线程运行到安全点时就主动轮询该中断标志，如果中断标志为true，就将当前线程暂停

     • 安全区域：

       • 在程序执行的情况下，程序每运行很短一段时间就能遇到一个安全点，但是程序如果因为sleep处于Blocked状态，此时程序无法响应JVM的暂停请求，无法去安全点进行中断，JVM也不能等待线程被唤醒，此时可以通过安全区域解决该问题

       • 安全区域是一段代码片段，在该代码片段中，对象的引用关系不会发生变化，因此在这段代码区域中的任何位置GC都是安全的

       • 运行到安全区域的线程会被标识为Safe Region，发生GC时，JVM会忽略掉标识为Safe Region的线程；当线程即将离开安全区域时会检查JVM是否已经完成了GC，如果已经完成了GC会继续运行，否则线程会暂停等待直到收到可以离开安全区域的信号

   • 引用：99%的场景都使用的强引用，类库或者框架源码中用到了软引用和弱引用，除强引用外其他三种引用都可以在包java.lang.ref下找到，都继承自抽象类java.lang.ref.Reference；以下特点都是在引用关系还在的情况下，如果引用关系已经不存在了即使是强引用关联的对象也会被回收；软引用和弱引用主要用于缓存场景；虚引用用于对象回收跟踪

     • 强引用：

       • 概念：类似Object obj = new Object()这种使用构造器创建一个新对象并将对象地址赋值给一个变量，这个变量就称为指向该对象的强引用；将一个强引用赋值给另一个变量对应变量也是强引用，任何情况下垃圾回收器都不会回收存在强引用关系的对象，强引用是创建对象默认的引用类型

       • 凡是具有强引用关联的对象都是可达的，都处于可触及状态；对应的软、弱、虚引用关联的对象都对应软、弱、虚可触及状态，处于这三种状态的对象在一定条件下都可以被回收；强引用是造成Java内存泄漏的主要原因

     • 软引用[SoftReference]：

       • 存在一类对象，当内存空间足够时希望对象保留在内存中；内存空间垃圾收集后还是紧张则希望抛弃这些对象

       • 系统将要OOM以前，会先将不可达对象进行回收，回收后如果发现内存还是不够就会将软引用关联的对象进行回收，回收后还是没有足够内存抛出OOM

       • 软引用通常用来实现内存敏感的缓存，高速缓存就使用的软引用，Mybatis的源码中一些内部类就使用了软引用

       • 软引用的创建，首先使用构造器如Object obj = new Object()声明一个强引用关联对象，使用软引用类关联的对象的构造器如SoftReference<Object> sf = new SoftReference<Object>(obj);创建一个软引用，然后使用obj=null销毁强引用，不销毁强引用软引用不会对GC造成影响；上述三行代码等价于SoftReference<Object> sf = new new SoftReference<Object>(new Object());一行代码；通过软引用的softReference.get()方法可以获取软引用封装的对象，如果对象已经被回收该方法返回null

       • 软引用对象的回收可以指定一个软引用队列，通过该队列可以跟踪对象的回收情况

     • 弱引用[WeakReference]：

       • 只要进行垃圾回收，只被弱引用关联的对象就会被回收

       • 弱引用对象的创建方式WeakReference<Object> weakReference = new new WeakReference<Object>(new Object());，也可以使用类似创建软引用的三行代码形式；也通过weakReference.get()来获取被软引用关联的对象，该对象被回收以后，weakReference.get()返回null

       • 弱引用对象的回收可以指定一个弱引用队列，通过该队列可以跟踪对象的回收情况

       • 像安卓系统的三级缓存，如果内存中存在图片就去内存中获取，内存中没有就去本地文件获取，本地文件没有就去网络中获取，内存中的图片缓存就可以使用软引用或者弱引用来关联，只在内存充足时保持缓存

       • 集合WeakHashMap<K,V>和弱引用相关，使用WeakHashMap存储图片信息内存不足时就会及时地回收内存数据，WeakHashMap中的Entry<K,V>是WeakHashMap的内部类，继承了WeakReference<Object>实现了Entry<K,V>，注意WeakHashMap只有key使用的是弱引用，值使用的是强引用，因此WeakHashMap中的对象除了集合本身对key的弱引用外，key对应对象没有其他引用，集合会自动丢弃该键值对让键值对对应对象自动被垃圾回收

     • 虚引用[PhantomReference、幽灵引用、幻影引用、幻像引用]：

       • 为一个对象设置虚引用关联的唯一目的是对象在被垃圾回收器回收时收到一个系统通知，此外虚引用不会对对象的回收造成任何影响即不会影响一个对象的生命周期，同时用户也无法通过虚引用来获取一个对象的实例，虚引用的唯一目的是跟踪对象的垃圾回收过程

       • 虚引用通过phantomReference.get()方法获取对象时总是获取的null，虚引用必须和引用队列一起使用，虚引用在调用构造器创建的同时必须提供一个引用队列作为参数如PhantomReference<Object> phantomReference = new PhantomReference<Object>(obj,referenceQueue<Object>);，用户可以自定义对referenceQueue中引用的自定义处理逻辑

       • 垃圾回收器回收一个对象时如果发现对象还有一个虚引用，会在回收对象后将该虚引用加入引用队列来通知用户对象的回收情况

     • 终结器引用[FinalReference]：

       • 修饰词为缺省，包内可用，实际开发中一般不使用

       • 用于实现对象的finalize()方法，终结器的构造方法也需要传入引用队列，终结器引用关联的对象在GC开始时，终结器引用也会入队列，由Finalizer线程通过终结器引用找到被引用的对象并调用该对象的finalize()方法，下次GC时对象被回收

   • OopMap

     • GC Roots枚举根节点的过程需要暂停用户线程，对栈进行扫描，对整个栈进行扫描很消耗性能，HotSpot采用了空间换时间的方法，使用OopMap存储栈上的对象引用信息，每个栈帧可能有多个OopMap，存储在栈帧的附加信息区域，GCRoots枚举根节点时直接通过遍历每个栈帧的OopMap找到栈上的根节点

     • OopMap中存储的数据

       • OopMap记录的是栈中某个寄存器或者栈帧的某个偏移量处存储了一个对象引用，OopMap中存储的是对象引用的位置